wp-cron నిలిపివేసి system cron ఎలా సెటప్ చేయాలి

WP-Cron అంటే ఏమిటి, system cron దాన్ని ఎందుకు భర్తీ చేస్తుంది

WP-Cron అనేది WordPress లోనే నిర్మితమైన task scheduler. ఇది ఎవరైనా page ను request చేసినప్పుడు మాత్రమే నడుస్తుంది. WordPress లోపల ఏదీ స్వయంగా మేల్కొని నడవదు. Cache నుంచి అందించని ప్రతి request సమయంలో WordPress scheduled jobs జాబితాను చదువుతుంది. ఏదైనా job అమలు కావాల్సి ఉంటే, పని చేయడానికి /wp-cron.php వద్ద తనకే మరో HTTP request పంపుతుంది. ఆ job ను system cron కు తరలిస్తే, ఆ నిమిషంలో site కు వెయ్యి మంది visitors ఉన్నా లేదా ఎవరూ లేకపోయినా, నిర్ణయించిన schedule ప్రకారం ఒక స్థిరమైన, అంచనా వేయగల run జరుగుతుంది.

వాస్తవ పనిని రెండు పంక్తులు చేస్తాయి: wp-config.php లోని constant మరియు crontab entry. ఈ guide లోని మిగతా భాగం ఆ రెండు పంక్తులు చెప్పని విషయాలను వివరిస్తుంది. Job ఏ user గా నడవాలి, scheduled events నిజంగా అమలయ్యాయని ఎలా నిర్ధారించాలి, అలాగే site లో ఏదీ ముద్రించకుండా setup విఫలమయ్యే మూడు మార్గాలు ఏమిటి అన్నది ఇందులో ఉంటుంది.

ఉదాహరణల్లో WordPress directory కోసం /srv/www/example.com ను, web server user కోసం www-data ను ఉపయోగిస్తారు. ప్రతి చోట మీ స్వంత paths మరియు user ను ఉపయోగించండి.

రద్దీగా ఉన్న సైట్‌లో cron ఖర్చును ఏ visitor ప్రారంభించాడు

Cache కాని ప్రతి request తనిఖీకి ఖర్చు కలిగిస్తుంది. WordPress cron option ను load చేసి timestamps ను పోలుస్తుంది. ఏదైనా పని due అయినప్పుడు అది spawn_cron() ను call చేస్తుంది. ఇది /wp-cron.php కు non-blocking loopback request పంపుతుంది. ఫలితం కోసం visitor వేచి ఉండడు. కానీ PHP worker వేచి ఉంటుంది. pm.max_children = 5 తో PHP-FPM నడుస్తున్న చిన్న VPSలో, ఒక నెమ్మదైన scheduled job మీ PHP capacityలో ఐదవ వంతును అది పూర్తయ్యే వరకు ఆక్రమిస్తుంది. ఇది మీ అత్యంత రద్దీగా ఉన్న నిమిషంలో ప్రారంభమయ్యే అవకాశం ఎక్కువ. ఆ సమయంలోనే ఎక్కువ page loads జరుగుతాయి.

WordPress duplicate runs ను పరిమితం చేస్తుంది. ఇది WP_CRON_LOCK_TIMEOUT lifetime కలిగిన lock ను తీసుకుంటుంది. Default గా ఇది 60 seconds ఉంటుంది. అందువల్ల ఒకేసారి వచ్చే visitors ఒక్కొక్కరూ run ను ప్రారంభించరు. ఈ lock duplication ను పరిమితం చేస్తుంది. కానీ పనిని request path నుంచి బయటకు తరలించదు.

ఇది ముఖ్యమా అని నిర్ణయించే ముందు, మీ స్వంత serverలో ఇది ఎంత తరచుగా run అవుతుందో లెక్కించండి. ప్రతి loopback web server access logలో కనిపిస్తుంది:

sudo grep -c 'wp-cron.php' /var/log/nginx/access.log

Apache బదులుగా /var/log/apache2/access.log లో రాస్తుంది. రోజుకు వేల సంఖ్యలో ఉండే count నిజమైన ఖర్చును సూచిస్తుంది. ఈ సంఖ్యను ఏదైనా మార్పుకు ముందు మరియు తరువాత VPS పనితీరును benchmark చేయడం లాగానే, ఒక articleలో చదవడం కాకుండా మీ స్వంత boxలో కొలవాలి.

Caching ఈ పరిస్థితిని మారుస్తుంది. Page cache ఎక్కువ requests ను static HTMLగా అందిస్తే, ఆ requests కోసం PHP అసలు run కాదు. అందువల్ల cron check కూడా జరగదు. బలంగా cached అయిన busy site, కింద ఉన్న quiet site లాగా ప్రవర్తించడం ప్రారంభిస్తుంది.

నిశ్శబ్ద సైట్‌లో ఏ సందర్శకుడు cron ను ప్రారంభిస్తే అది విఫలమవుతుంది

సందర్శకులు లేకపోతే cron కూడా పనిచేయదు. రోజుకు కొద్దిమంది మాత్రమే సందర్శించే సైట్‌లో scheduled jobs కూడా ఆ సందర్శనలు వచ్చిన యాదృచ్ఛిక సమయాల్లోనే రోజుకు కొద్దిసార్లు నడుస్తాయి.

లక్షణాలన్నీ ఒకే విధంగా కనిపిస్తాయి. 09:00కు షెడ్యూల్ చేసిన post, ఎవరో ఒకరు page ను load చేసే వరకు posts జాబితాలో Missed schedule గా కనిపిస్తుంది. Backup plugins రాత్రి సమయంలో పనిచేయవు. Update checks ఆలస్యమవుతాయి. అందువల్ల security release ఇప్పటికే అందుబాటులో ఉన్నప్పటికీ dashboard లో update చేయాల్సినవి ఏవీ లేవని కనిపిస్తుంది. Order emails, renewal notices, expiry warnings ఆలస్యంగా పంపబడతాయి.

ఇవేవీ error ను log చేయవు. WordPress దృష్టిలో job ఆలస్యం కాలేదు, ఎందుకంటే అది ఎప్పుడూ ప్రారంభం కాలేదు.

దశ 1: wp-config.php లో visitor trigger ను ఆపండి

/srv/www/example.com/wp-config.php ను తెరిచి, ఈ constant ను జోడించండి:

define( 'DISABLE_WP_CRON', true );

/* That's all, stop editing! Happy publishing. */ ఉన్న line కు పైన దీన్ని ఉంచండి. ఆ comment కు కింద ఉన్న line కు wp-settings.php అవసరం, అలాగే wp-settings.php వద్ద WordPress cron check ను init కు hook చేస్తుంది. ఆ require తర్వాత constant ను నిర్వచిస్తే అది మార్పు చేయడానికి చాలా ఆలస్యం అవుతుంది. Trigger కొనసాగుతున్నప్పటికీ file సరిగ్గా ఉన్నట్లు కనిపిస్తుంది.

Line మీరు ఉద్దేశించిన స్థానంలో ఉందో నిర్ధారించండి:

grep -n "DISABLE_WP_CRON\|stop editing" /srv/www/example.com/wp-config.php

ఈ constant events schedule చేయడాన్ని ఆపదు. Plugins మునుపటిలాగే queue కు jobs జోడిస్తూనే ఉంటాయి. ఇది page loads ఆ queue ను run చేయడాన్ని మాత్రమే ఆపుతుంది. అందువల్ల step 3 పూర్తయ్యే వరకు queue ఇక run కాదు.

/wp-cron.php కు వచ్చే direct requests ను కూడా ఇది block చేయదు. ఎవరైనా ఇప్పటికీ ఆ URL ను request చేయవచ్చు. సాధారణంగా ఇది హానికరం కాదు, ఎందుకంటే file due అయిన jobs ను మాత్రమే run చేస్తుంది. మీ web server config లో దీన్ని block చేయడం optional. Block చేస్తే, ఈ guide చివర్లో ఉన్న curl fallback కూడా పనిచేయదు.

దశ 2: WP-CLI ఇన్‌స్టాల్ చేయండి

WP-CLI అనేది WordPress కోసం అధికారిక command line సాధనం. దీనికి PHP command line binary అవసరం. ఇది web server యొక్క PHP module కు వేరు package.

php -v
sudo apt install -y php-cli

అధికారిక install guide సిఫారసు చేసే phar build నుంచి WP-CLI ను ఇన్‌స్టాల్ చేయండి:

cd /tmp
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
php wp-cli.phar --info
chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp
wp --info

php wp-cli.phar --info PHP binary path, PHP version, WP-CLI version ను చూపిస్తుంది. ఈ మూడు కనిపిస్తే phar సరిగ్గా పనిచేస్తుంది. August 2026 నాటికి install guide కనీస PHP version గా 7.2.24 ను పేర్కొంటుంది. Ubuntu 24.04 లో PHP 8.3 వస్తుంది కాబట్టి, ప్రస్తుత server ఆ కనీస స్థాయికంటే చాలా పైగా ఉంటుంది. తరువాత sudo wp cli update తో update చేయండి.

WP-CLI ను site user గా నడపండి. root గా ఎప్పుడూ నడపవద్దు:

sudo -u www-data /usr/local/bin/wp --path=/srv/www/example.com core version

root గా నడిపితే WP-CLI ప్రారంభం కావడానికి నిరాకరిస్తుంది:

Error: YIKES! It looks like you're running this as root.

అది --allow-root ను సూచిస్తుంది. ఇక్కడ దాన్ని ఉపయోగించవద్దు. కారణం కింది మొదటి failure mode లో ఉంది.

sudo -u www-data -i పనిచేయదని కూడా గమనించండి. ఆ account యొక్క login shell /usr/sbin/nologin కావడం వల్ల This account is currently not available. వస్తుంది. Command ను నేరుగా sudo -u కు పంపితే login shell దాటవేయబడుతుంది. అందువల్ల అది సరిగ్గా నడుస్తుంది.

ఇప్పుడు WordPress స్వయంగా step 1 లోని constant ను గుర్తిస్తుందో నిర్ధారించండి:

sudo -u www-data /usr/local/bin/wp --path=/srv/www/example.com eval 'var_dump( DISABLE_WP_CRON );'

అది bool(true) ను చూపిస్తుంది. undefined constant గురించి fatal error వస్తే, define() line చేరుకోవడం లేదని అర్థం. సాధారణంగా ఆ line require తర్వాత కాకుండా దాని కింద ఉండటమే కారణం.

దశ 3: సరైన userగా cron entryని జోడించండి

PHP రాసే files కు owner అయిన userనే సరైన user. రెండు చివరలను తనిఖీ చేయండి:

stat -c '%U %G' /srv/www/example.com/wp-content/uploads
grep -E '^(user|group) = ' /etc/php/8.3/fpm/pool.d/www.conf

డిఫాల్ట్ Ubuntu installలో రెండింటి సమాధానం www-data. సొంత userతో ప్రత్యేక PHP-FPM poolను siteకు కేటాయించి ఉంటే, సాధారణంగా Ubuntu 24.04లోని LAMP stack per-site setupలో ఉండే విధంగా, కింద ఇచ్చిన అన్నిచోట్లా ఆ userనే ఉపయోగించండి.

ఆ user రాయగలిగే log directoryని సృష్టించండి:

sudo install -d -o www-data -g www-data -m 750 /var/log/wp-cron

ఆ user యొక్క crontabను సవరించండి:

sudo crontab -u www-data -e

ఒక lineను జోడించండి:

*/5 * * * * /usr/bin/flock -n /run/lock/wp-cron-example.lock /usr/local/bin/wp --path=/srv/www/example.com cron event run --due-now >> /var/log/wp-cron/example.log 2>&1

భాగాలవారీగా చూద్దాం. */5 ప్రతి ఐదు నిమిషాలకు దీన్ని నడుపుతుంది. flock -n lock fileను తీసుకుని, మునుపటి run ఇంకా దాన్ని పట్టుకుని ఉంటే వెంటనే నిలిచిపోతుంది. /usr/local/bin/wp absolute path; cronకు ఇది అవసరం. --path commandను ఏ working directory నుంచైనా నడవడానికి అనుమతిస్తుంది. --due-now queueలో సమయం వచ్చిన eventsను మాత్రమే నడుపుతుంది; queueలోని ప్రతి eventను కాదు. redirect సాధారణ output మరియు errorsను మీరు చదవగలిగే ఒక fileకు పంపుతుంది.

ఆ redirect ఆచరణలో తప్పనిసరి. Cron job outputను దాని userకు mail చేస్తుంది. చాలా VPS imagesలో mail transfer agent install చేసి ఉండదు. అందువల్ల cron (CRON) info (No MTA installed, discarding output)ను log చేసి, outputను తొలగిస్తుంది. Fileలో ఉంచితే ఆధారం మిగులుతుంది.

File save అయిందో తనిఖీ చేయండి:

sudo crontab -u www-data -l

అనేక sites ఉంటే, అవన్నీ ఒకేసారి ప్రారంభం కాకుండా staggered minutesతో ప్రతి siteకు ఒక్కో line ఉపయోగించండి:

*/5 * * * * /usr/bin/flock -n /run/lock/wp-cron-one.lock /usr/local/bin/wp --path=/srv/www/one.example.com cron event run --due-now >> /var/log/wp-cron/one.log 2>&1
2-59/5 * * * * /usr/bin/flock -n /run/lock/wp-cron-two.lock /usr/local/bin/wp --path=/srv/www/two.example.com cron event run --due-now >> /var/log/wp-cron/two.log 2>&1

దాన్ని rotate చేయకపోతే log నిరంతరం పెరుగుతుంది. /etc/logrotate.d/wp-cronని రాయండి:

/var/log/wp-cron/*.log {
    weekly
    rotate 4
    missingok
    notifempty
    compress
    create 640 www-data www-data
}

ఏదీ మార్చకుండా ఇది parse అవుతుందో తనిఖీ చేయండి: sudo logrotate --debug /etc/logrotate.d/wp-cron.

దశ 4: షెడ్యూల్ చేసిన ఈవెంట్లు నిజంగా అమలయ్యాయో నిర్ధారించండి

crontab లోని ఒక లైన్ విజయవంతంగా save అయిందంటే ఏదీ నిర్ధారించబడినట్లు కాదు. తక్కువ ఖర్చుతో చేసే తనిఖీ నుంచి సమస్యను స్పష్టంగా నిర్ధారించే తనిఖీ వరకు క్రమంగా పరిశీలించండి.

ముందుగా, cron ఆదేశాన్ని ప్రారంభించిందా? cron తన unit పేరుతో journal లో logs రాస్తుంది:

journalctl -u cron.service --since "15 min ago" | grep wp

ముందు ఉన్న timestamp మరియు host name తొలగిస్తే, ఆరోగ్యకరమైన entry ఇలా కనిపిస్తుంది:

CRON[24913]: (www-data) CMD (/usr/bin/flock -n /run/lock/wp-cron-example.lock /usr/local/bin/wp --path=/srv/www/example.com cron event run --due-now >> /var/log/wp-cron/example.log 2>&1)

ఈ లైన్ cron మీ ఆదేశాన్ని www-data గా ప్రారంభించిందని అర్థం. ఆ ఆదేశం విజయవంతంగా పనిచేసిందో లేదో ఇది చెప్పదు.

రెండవది, WordPress ఏదైనా execute చేసిందా? log file ను చదవండి:

sudo tail -n 20 /var/log/wp-cron/example.log

WP-CLI ప్రతి event కు ఒక లైన్, తరువాత మొత్తం సంఖ్యను print చేస్తుంది:

Executed the cron event 'wp_version_check' in 0.418s.
Success: Executed a total of 2 cron events.

Errors అదే file లోకి రాస్తాయి. ఇదే 2>&1 యొక్క ముఖ్య ఉద్దేశం. చాలా runs లో అమలు చేయాల్సిన event ఏదీ ఉండదు, కాబట్టి చాలా తక్కువ output రాస్తాయి. అందువల్ల పని వేచి ఉన్నదని మీకు తెలిసిన run తర్వాత file ను చదవండి.

మూడవది, ప్రారంభం నుంచి ముగింపు వరకు నిర్ధారించండి. ఒక marker event ను schedule చేసి, అది తొలగిపోవడాన్ని గమనించండి:

sudo -u www-data /usr/local/bin/wp --path=/srv/www/example.com cron event schedule wp_cli_cron_check now
sudo -u www-data /usr/local/bin/wp --path=/srv/www/example.com cron event list --fields=hook,next_run_relative --format=csv | grep wp_cli_cron_check

ఒక interval కోసం వేచి ఉండి, తరువాత list command ను మళ్లీ run చేయండి. hook కనిపించదు, ఎందుకంటే ఒకసారి మాత్రమే అమలయ్యే event run అయినప్పుడు queue నుంచి తొలగించబడుతుంది. ఆ hook name కు ఏ plugin callback ను register చేయదు, కాబట్టి దాన్ని run చేయడం వల్ల site పై మరే ఇతర చర్య జరగదు. రెండు intervals తర్వాత కూడా hook జాబితాలో ఉంటే, queue run కావడం లేదు. సమస్య cron లోనా లేదా WP-CLI లోనా అనేది మొదటి రెండు తనిఖీలు చెబుతాయి.

దీనికోసం wp cron test ఉపయోగించవద్దు. ఆ command visitor-triggered spawning పనిచేస్తుందో లేదో తనిఖీ చేస్తుంది. DISABLE_WP_CRON నిజమైనప్పుడు అది error ఇస్తుంది. సరిగ్గా configure చేసిన server లో ఆ error ఊహించిన output మాత్రమే; అది fault కాదు.

systemd timer ప్రత్యామ్నాయం

సిస్టమ్‌లోని మిగతా షెడ్యూల్ పనులు ఇప్పటికే systemd services and timers ద్వారా నడుస్తుంటే, WordPress ను కూడా అదే విధానంలో అమలు చేయండి. అప్పుడు ప్రతి run systemctl list-timers లో కనిపిస్తుంది. అలాగే, rotate చేయాల్సిన file కు బదులుగా output journal కు వెళ్తుంది.

/etc/systemd/system/wp-cron-example.service రాయండి:

[Unit]
Description=Run due WordPress cron events for example.com

[Service]
Type=oneshot
User=www-data
Group=www-data
ExecStart=/usr/local/bin/wp --path=/srv/www/example.com cron event run --due-now

తర్వాత /etc/systemd/system/wp-cron-example.timer రాయండి:

[Unit]
Description=Run WordPress cron for example.com every 5 minutes

[Timer]
OnCalendar=*:0/5
AccuracySec=30s
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now wp-cron-example.timer
systemctl list-timers wp-cron-example.timer
journalctl -u wp-cron-example.service -n 20

systemd ఒకే service కి చెందిన రెండు copies ను ఒకేసారి run చేయదు. కాబట్టి ఈ version కు flock అవసరం లేదు. యంత్రం off లో ఉన్నప్పుడు miss అయిన run ను ఇది catch up చేస్తుంది. crontab entry ఇలా చేయలేదు. Persistent=true

crontab లేదా timer లో ఒకదాన్ని ఎంచుకోండి. ఒకే site పై రెండింటినీ run చేస్తే queue రెండుసార్లు drain అవుతుంది. Email లేదా order job రెండుసార్లు run కావడం మీ customers కు కనిపిస్తుంది.

cron job ను root గా ఎందుకు అమలు చేయకూడదు

ఇది setup విఫలమయ్యే మూడు మార్గాల్లో మొదటిది. Job ను root యొక్క crontab లో ఉంచితే, WP-CLI ఏ పని చేయకముందే ఆగిపోతుంది:

Error: YIKES! It looks like you're running this as root.

Queue ఎప్పటికీ అమలు కాదు. Output ను redirect చేయకపోతే ఆ message మీకు కనిపించదు. ప్రమాదకరమైన పరిష్కారం --allow-root జోడించడం. అలా చేస్తే ఆ run సమయంలో plugin రాసే ప్రతి file root కు చెందినదిగా మారుతుంది. తరువాతి web request www-data గా అమలవుతుంది. ఆ directories లో రాయలేకపోవడంతో site ఈ విధమైన errors ను చూపించడం ప్రారంభిస్తుంది:

Unable to create directory wp-content/uploads/2026/08. Is its parent directory writable by the server?

Ownership ను సరిచేసి, తరువాత job ను తరలించండి:

sudo chown -R www-data:www-data /srv/www/example.com/wp-content

root యొక్క crontab మరియు www-data యొక్క crontab వేర్వేరు files. కాబట్టి ఒకదానిలోని line ను తొలగించడం వల్ల మరొకదానిలోని line తొలగిపోదు. రెండింటినీ పరిశీలించండి:

sudo crontab -u root -l
sudo crontab -u www-data -l

cron wp: not found అని ఎందుకు నివేదిస్తుంది

ఇది రెండవ వైఫల్యం. Cron వినియోగదారు jobs కు చాలా చిన్న PATH ఇస్తుంది: /usr/bin:/bin. WP-CLI /usr/local/bin లో install అవుతుంది. అది ఆ జాబితాలో లేదు. Job ప్రారంభమై, ఒక సెకను భాగంలోనే విఫలమవుతుంది. Log లో ఒకే పంక్తి ఉంటుంది:

/bin/sh: 1: wp: not found

ఊహించకుండా cron environment ను మీరే పరిశీలించండి. తాత్కాలికంగా ఈ పంక్తిని జోడించండి:

*/5 * * * * env > /tmp/cron-env.txt 2>&1

ఒక interval తర్వాత /tmp/cron-env.txt ను చదివి, ఆ పంక్తిని తొలగించండి. ఆ file లోని PATH= విలువ మీ job కు లభించే విలువతో సరిగ్గా సమానం.

దీనికి రెండు పరిష్కారాలు ఉన్నాయి. 3వ దశలో చూపినట్లుగా absolute path /usr/local/bin/wp ను ఉపయోగించండి. లేదా crontab పైభాగంలో, ప్రతి job line కు ముందు, PATH ను ఒకసారి సెట్ చేయండి:

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

ఇదే సమస్య మరో స్థాయిలో కూడా ఉంటుంది. wp phar, #!/usr/bin/env php తో ప్రారంభమవుతుంది. అందువల్ల shell కూడా php ను కనుగొనగలగాలి. PHP /usr/bin వెలుపల ఉంటే, custom builds మరియు control panel builds లో ఇది జరుగుతుంది, మీకు ఈ error వస్తుంది:

/usr/bin/env: 'php': No such file or directory

అలాంటి సందర్భంలో interpreter ను స్పష్టంగా call చేయండి. ఉదాహరణకు /usr/local/bin/php /usr/local/bin/wp --path=/srv/www/example.com cron event run --due-now.

ఒక నిమిషం interval అసలు సమస్యను ఎందుకు మళ్లీ సృష్టిస్తుంది

ఇది మూడవ వైఫల్యం. * * * * * ఐదు నిమిషాల కంటే సురక్షితంగా అనిపిస్తుంది. కానీ busy site లో ఇది మిమ్మల్ని మళ్లీ ప్రారంభ స్థితికి తీసుకెళ్తుంది. ఒక run పూర్తి కావడానికి interval కంటే ఎక్కువ సమయం పడితే, మొదటి run ఇంకా కొనసాగుతుండగానే తదుపరి run ప్రారంభమవుతుంది. పది నిమిషాల తర్వాత పది PHP processes ఉంటాయి. ప్రతి process తన స్వంత memory మరియు database connection ను కలిగి ఉంటుంది.

నేరుగా pileup ఉందో లేదో పరిశీలించండి:

ps -eo etimes,user,args | grep '[c]ron event run'

etimes అనేది process వయస్సును seconds లో చూపిస్తుంది. ఒక line ఉంటే స్థితి సరిగా ఉంది. మీ interval కంటే చాలా ఎక్కువ వయస్సు కలిగిన అనేక lines కనిపిస్తే runs ఒకదానిపై మరొకటి పేరుకుపోతున్నాయని అర్థం. చిన్న VPS లో ఇది MySQL Too many connections error కు దారితీయవచ్చు. లేదా memory ను తిరిగి పొందడానికి kernel PHP ను terminate చేయవచ్చు. దీన్ని sudo dmesg -T | grep -i 'killed process' తో నిర్ధారించవచ్చు.

WP-CLI wp-cron.php కు request పంపడం బదులుగా event callbacks ను నేరుగా అమలు చేస్తుంది. అందువల్ల duplicate spawns ను నిరోధించడానికి WordPress ఉపయోగించే 60 seconds lock ఇక్కడ వర్తించదు. Step 3 entry లోని flock -n ఇప్పుడు overlap ను నిరోధిస్తుంది. Skip అయిన run design ప్రకారం వెంటనే, ఎటువంటి output లేకుండా exit అవుతుంది.

మీరు నిజంగా ఆధారపడే అత్యల్ప schedule ఆధారంగా interval ను ఎంచుకోండి. ముందుగా ఒక run ఎంత సమయం తీసుకుంటుందో కొలవండి:

time sudo -u www-data /usr/local/bin/wp --path=/srv/www/example.com cron event run --due-now

ఐదు నిమిషాలు సరైన default. 09:00 కు schedule చేసిన post 09:05 లోపు publish అవుతుంది. Site లో time-critical పనులు ఏవీ లేకపోతే పదిహేను నిమిషాలు సరిపోతాయి. Stores మరియు queue-driven plugins కు నిజంగా అవసరమైనప్పుడు మాత్రమే ఒక నిమిషం interval ఉపయోగించండి. అదీ ఒక run కొన్ని seconds లో పూర్తవుతుందని నిర్ధారించిన తర్వాత మాత్రమే.

WP-CLIను ఇన్‌స్టాల్ చేయలేకపోతే

కొన్ని hosts shell tools ను నిరోధిస్తాయి. wp-cron.php కు సాధారణ HTTP request పంపితే అదే queue నడుస్తుంది. అయితే అది మొత్తం web stack ద్వారా నడుస్తుంది:

*/5 * * * * /usr/bin/curl -sS --max-time 120 "https://example.com/wp-cron.php?doing_wp_cron" > /dev/null

మీరు కోల్పోయేవి ఇవి:

• ఈ run ను web server మరియు PHP-FPM request timeouts పరిమితం చేస్తాయి. అందువల్ల ఎక్కువసేపు నడిచే job మధ్యలోనే ఆగిపోవచ్చు.
• certificate చెల్లుబాటు అయ్యి ఉండాలి. లేకపోతే curl, SSL certificate problem తో ఆగిపోతుంది. కాబట్టి nginxలో Certbot ద్వారా renewals సక్రమంగా పనిచేసేలా ఉంచండి.
• Page caching wp-cron.php ను cache చేయకూడదు. లేకపోతే cron requests కు cached response లభిస్తుంది, ఏదీ run కాదు.
• ప్రతి event కు output అందదు. అందువల్ల job నడిచిందనడానికి అది చేసిన ప్రభావమే ఏకైక ఆధారం.

విజయం సాధించినప్పుడు -sS curl ను నిశ్శబ్దంగా ఉంచుతుంది. అయితే errors ను ముద్రిస్తుంది. cron job లో మీకు కావలసింది ఇదే.

సర్వర్ షెడ్యూల్‌లో ఇంకా ఏమి ఉండాలి

system cron WordPress queue ను నిర్వహించడం ప్రారంభించిన తర్వాత, సర్వర్‌లోని మిగతా సాధారణ పనులను కూడా మీరు పర్యవేక్షించగలిగే అదే వ్యవస్థలో ఉంచండి. ఆపరేటింగ్ సిస్టమ్ security patches కోసం మీరు స్వయంగా నిర్వహించే cron line కంటే unattended upgrades ఉపయోగించాలి. WordPress plugin మరియు theme updates వేరే నిర్ణయం: crontab లోని wp plugin update --all ఎవరూ పర్యవేక్షించని సమయంలో రాత్రి 3 గంటలకు నడిచి live site ను సులభంగా దెబ్బతీయవచ్చు. అందువల్ల దీన్ని ఉద్దేశపూర్వకంగా అమలు చేయండి లేదా staging దశ మరియు backup తర్వాత అమలు చేయండి.

FAQ

షెడ్యూల్ చేసిన పోస్టులు ప్రచురించకుండా WP-Cron ను నిలిపివేస్తే ఆగిపోతాయా?

లేదు. Queue ను మరేదైనా ప్రక్రియ నడిపినంతకాలం అవి ప్రచురితమవుతాయి. DISABLE_WP_CRON పేజీ లోడ్లు queue ను trigger చేయడాన్ని మాత్రమే ఆపుతుంది. Events మునుపటిలాగే schedule అవుతాయి. 09:00కు సెట్ చేసిన పోస్ట్, 09:00 తర్వాత జరిగే మొదటి cron run లో ప్రచురితమవుతుంది. కాబట్టి ఐదు నిమిషాల interval ఉంటే అది 09:05లోపు ప్రచురితమవుతుంది. మీరు constant ను సెట్ చేసి, cron entry ను ఎప్పుడూ జోడించకపోతే, queue ను ఏదైనా ప్రక్రియ నడిపే వరకు ఆ పోస్ట్ Missed schedule గుర్తుతో list లోనే ఉంటుంది.

WordPress cron job ను ఏ user నడపాలి?

PHP రాసే files కు owner అయిన user నడపాలి. Default Ubuntu install లో అది www-data. stat -c '%U %G' /srv/www/example.com/wp-content/uploads తో తనిఖీ చేసి, మీ PHP-FPM pool config లోని user = line తో పోల్చండి. Job ను root గా నడిపితే WP-CLI YIKES error తో ఆగిపోతుంది. --allow-root తో దాన్ని బలవంతంగా నడిపితే wp-content లో root-owned files ఏర్పడతాయి. వాటిని web server తరువాత రాయలేను.

system cron, WordPress cron ను ఎంత తరచుగా నడపాలి?

చాలా sites కు ప్రతి ఐదు నిమిషాలకు ఒకసారి సరిపోతుంది. మీరు నిజంగా ఆధారపడే అత్యల్ప schedule కు interval ను సరిపోల్చండి. ఒక run కు పట్టే సమయం కంటే interval తగినంత ఎక్కువగా ఉండాలి. ఆ సమయాన్ని WP-CLI command ముందు time ఉంచి కొలవచ్చు. Busy site లో ఒక నిమిషం intervals ఉంటే runs ఒకదానిపై మరొకటి పేరుకుపోవచ్చు, flock వాటిని నియంత్రించనంతవరకు.

WP-Cron ను నిలిపివేసిన తర్వాత wp cron test ఎందుకు విఫలమవుతుంది?

ఆ command visitor-triggered spawning ను పరీక్షిస్తుంది. DISABLE_WP_CRON true గా సెట్ చేసి ఉంటే అది error ను చూపిస్తుంది. ఈ విధంగా configure చేసిన server లో ఇది సరైన ఫలితం. బదులుగా system cron path ను తనిఖీ చేయండి. /var/log/wp-cron/example.log ను చదవండి. లేదా wp cron event schedule తో marker event ను schedule చేసి, తదుపరి run తర్వాత అది wp cron event list నుంచి తొలగించబడిందో నిర్ధారించండి.

నాకు WP-CLI అవసరమా, లేక wp-cron.php కు curl సరిపోతుందా?

curl పనిచేస్తుంది. WP-CLI ను install చేయలేని సందర్భంలో అదే సరైన ఎంపిక. ఇది web server ద్వారా WordPress ను load చేస్తుంది కాబట్టి నెమ్మదిగా ఉంటుంది. Request timeout కూడా దీనికి వర్తిస్తుంది. WP-CLI events ను web timeout లేకుండా command-line PHP process లో నడుపుతుంది. ప్రతి event కు దాని duration తో ఒక line ను print చేస్తుంది. అందువల్ల ఏది run అయిందో, ఎంత సమయం పట్టిందో log ద్వారా ఖచ్చితంగా తెలుస్తుంది.