WP-Cron నిలిపివేసి system cron ఎలా ఉపయోగించాలి

WP-Cron అంటే ఏమిటి, దాని స్థానంలో system cron ఎందుకు ఉపయోగించాలి

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

నిజమైన పనిని రెండు పంక్తులు చేస్తాయి: 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 ప్రేరేపించాడు

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

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

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

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

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

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 అవసరం, అలాగే WordPress cron check ను init కు hook చేసే స్థలం wp-settings.php. ఆ require తర్వాత constant ను నిర్వచిస్తే, మార్పు చేయడానికి అది చాలా ఆలస్యమవుతుంది. File సరిగ్గా కనిపించినా trigger కొనసాగుతుంది.

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

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

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

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

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

WP-CLI అనేది WordPress కోసం అధికారిక command line tool. దీనికి 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 7.2.24 కనిష్ఠ version గా ఉంది. 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 దాటవేయబడుతుంది. అందువల్ల అది సరిగ్గా నడుస్తుంది.

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

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 వరకు execution చేరడం లేదని అర్థం. సాధారణంగా ఆ 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

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

ఆ 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 లోని ప్రతి event ను కాకుండా, సమయం వచ్చిన events ను మాత్రమే అమలు చేస్తుంది. 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 ను పరిశీలించండి:

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 లోని ఒక line విజయవంతంగా save అయిందంటే దానితో ఏదీ నిర్ధారించబడదు. తక్కువ ఖర్చుతో చేసే తనిఖీ నుంచి వాస్తవాన్ని నిర్ధారించే తనిఖీ వరకు క్రమంగా పరిశీలించండి.

మొదట, cron ఆ command ను ప్రారంభించిందా? cron తన స్వంత unit కింద journal లో logs రాస్తుంది:

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

సరైన entry ఇలా ఉంటుంది. ప్రారంభంలోని timestamp మరియు host name తొలగించబడ్డాయి:

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)

ఆ line ద్వారా cron మీ command ను www-dataగా ప్రారంభించిందని తెలుస్తుంది. ఆ command విజయవంతంగా పనిచేసిందో లేదో మాత్రం దాని ద్వారా తెలియదు.

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

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

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

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

Errors కూడా అదే file లో చేరతాయి. 2>&1 ఉపయోగించడానికి ఇదే ప్రధాన కారణం. చాలా runs లో అమలు చేయాల్సినవి ఏవీ ఉండవు, కాబట్టి చాలా తక్కువ output మాత్రమే రాయబడుతుంది. అందువల్ల pending work ఉందని మీకు తెలిసిన run తర్వాత file ను చదవండి.

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

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 కనిపించదు, ఎందుకంటే one-off event అమలైనప్పుడు 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 true అయినప్పుడు అది error చూపిస్తుంది. సరిగ్గా configured చేసిన server లో ఆ error రావడం expected output, fault కాదు.

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

సర్వర్‌లోని మిగిలిన షెడ్యూల్ పనులు ఇప్పటికే systemd services and timers ద్వారా నడుస్తుంటే, WordPress‌ను కూడా అదే విధానంలో అమలు చేయండి. అప్పుడు ప్రతి run systemctl list-timers లో కనిపిస్తుంది. Output‌ను rotate చేయాల్సిన ప్రత్యేక fileకు బదులుగా 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ను ఒకేసారి అమలు చేయదు. అందువల్ల ఈ విధానానికి flock అవసరం లేదు. యంత్రం off‌లో ఉన్నప్పుడు missed అయిన run‌ను Persistent=true తిరిగి అమలు చేస్తుంది. crontab entryలో ఈ సామర్థ్యం ఉండదు.

crontab లేదా timerలో ఒకదానిని ఎంచుకోండి. ఒకే siteపై రెండింటినీ అమలు చేస్తే queue రెండుసార్లు drain అవుతుంది. Email లేదా order jobలు duplicateగా 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 గా అమలవుతుంది. ఆ user ఆ directories లో రాయలేడు. Site ఈ విధమైన messages చూపించడం ప్రారంభిస్తుంది:

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 ను తొలగించడం మరొకదానిని ప్రభావితం చేయదు. రెండింటినీ పరిశీలించండి:

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

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

ఇది రెండో వైఫల్యం. Cron user jobs కోసం చాలా చిన్న PATH ను అందిస్తుంది: /usr/bin:/bin. WP-CLI /usr/local/bin లో ఇన్‌స్టాల్ అవుతుంది. ఆ మార్గం ఆ జాబితాలో ఉండదు. 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 కు లభించే విలువతో ఖచ్చితంగా సమానం.

దీనికి రెండు పరిష్కారాలు ఉన్నాయి. Step 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 ను స్పష్టంగా invoke చేయండి. ఉదాహరణకు /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 ను విడిగా ఉపయోగిస్తుంది.

నేరుగా processes పేరుకుపోతున్నాయో చూడండి:

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

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

WP-CLI wp-cron.php కు request పంపడం కాకుండా event callbacks ను నేరుగా run చేస్తుంది. అందువల్ల duplicate spawns ను నిరోధించడానికి WordPress ఉపయోగించే 60 second lock ఇక్కడ వర్తించదు. Step 3 entry లోని flock -n ఇప్పుడు overlap ను నిరోధిస్తుంది. Skip అయిన run వెంటనే, ఎలాంటి output లేకుండా exit అవుతుంది. ఇది ఉద్దేశపూర్వక ప్రవర్తన. Overlap ను crontab లోనే పరిష్కరించాలి. Host kernel దాన్ని మీ తరఫున పరిష్కరించదు. Linux kernel 7.2 లో చేర్చిన cache aware task placement కూడా process ఏ core పై run అవుతుందో మాత్రమే నిర్ణయిస్తుంది. మీరు ఎన్ని processes ప్రారంభించారో అది నియంత్రించదు.

మీరు నిజంగా ఆధారపడే అతి తక్కువ 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 పనులు ఏవీ లేకపోతే పదిహేను నిమిషాలు సరిపోతుంది. నిజంగా తక్కువ interval అవసరమయ్యే stores మరియు queue driven plugins కోసం మాత్రమే one minute ఉపయోగించండి. అదీ ఒక run కొన్ని seconds లో పూర్తవుతుందని నిర్ధారించిన తర్వాత మాత్రమే.

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

కొన్ని hosts shell tools ను నిరోధిస్తాయి. wp-cron.php కు plain 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 లభిస్తుంది మరియు ఏదీ నడవదు.
• ప్రతి event కు output లభించదు. అందువల్ల job నడిచిందని నిర్ధారించే ఏకైక ఆధారం అది కలిగించిన ప్రభావమే.

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

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

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

FAQ

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

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

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 వాటిలో రాయలేడు.

WordPress cron ను system 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 చూపిస్తుంది. ఈ విధంగా configured చేసిన 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 web timeout లేకుండా command line PHP process లో events ను నడుపుతుంది. ప్రతి event కు దాని duration తో ఒక line ను print చేస్తుంది. అందువల్ల ఏది నడిచింది, ఎంత సమయం పట్టింది అనే విషయం log ద్వారా స్పష్టంగా తెలుస్తుంది.