WordPress-ல் WP-Cron-ஐ முடக்கி System Cron பயன்படுத்துவது

wp-cron என்றால் என்ன, ஏன் system cron அதை மாற்றுகிறது

WP-Cron என்பது WordPress-ல் உள்ளமைக்கப்பட்ட ஒரு task scheduler ஆகும். ஒரு பயனர் பக்கத்தை கோரும்போது மட்டுமே இது இயங்கும். WordPress-க்குள் எந்தவொரு செயலும் தானாகவே இயங்காது. Cache-ல் இருந்து வழங்கப்படாத ஒவ்வொரு கோரிக்கையின் போதும், WordPress திட்டமிடப்பட்ட பணிகளின் பட்டியலை வாசிக்கும். ஏதேனும் பணி நிலுவையில் இருந்தால், அந்த வேலையைச் செய்ய அது /wp-cron.php-க்கு மீண்டும் ஒரு HTTP கோரிக்கையை தனக்குத்தானே அனுப்பும். அந்தப் பணியை system cron-க்கு மாற்றுவதன் மூலம், அந்த நிமிடத்தில் தளத்திற்கு ஆயிரம் பார்வையாளர்கள் வந்தாலும் அல்லது யாரும் வராவிட்டாலும், ஒரு குறிப்பிட்ட கால அட்டவணையில் பணி சரியாக நடப்பதை உறுதி செய்யலாம்.

இரண்டு வரிகள் இந்த வேலையைச் செய்கின்றன: wp-config.php-ல் உள்ள ஒரு constant மற்றும் ஒரு crontab entry. இந்த வழிகாட்டியில் உள்ள மற்ற அனைத்தும் அந்த இரண்டு வரிகள் சொல்லாத தகவல்களாகும். எந்த user-ஆக அந்தப் பணி இயங்க வேண்டும், திட்டமிடப்பட்ட நிகழ்வுகள் உண்மையில் நடந்தன என்பதை எப்படி உறுதிப்படுத்துவது, மற்றும் தளத்தில் எந்தப் பிழையும் காட்டாமல் இந்த அமைப்பு தோல்வியடையும் மூன்று வழிகள் ஆகியவற்றை இது விளக்குகிறது.

இந்த உதாரணங்கள் /srv/www/example.com-ஐ WordPress directory-ஆகவும், www-data-ஐ web server user-ஆகவும் பயன்படுத்துகின்றன. எல்லா இடங்களிலும் உங்கள் சொந்த paths மற்றும் user-ஐ மாற்றிக்கொள்ளவும்.

busy site-ல் எந்த visitor cron-ஐத் தூண்டுகிறார் என்பதைக் கண்டறிதல்

ஒவ்வொரு uncached request-ம் இந்தச் சோதனையைச் செய்கிறது. WordPress cron option-ஐ load செய்து, timestamps-ஐ ஒப்பிடுகிறது. ஏதேனும் பணி நிலுவையில் இருந்தால், அது spawn_cron()-ஐ அழைக்கிறது. இது /wp-cron.php-க்கு non-blocking loopback request-ஐ அனுப்புகிறது. இதற்காக visitor காத்திருக்க வேண்டியதில்லை. ஆனால், ஒரு PHP worker காத்திருக்க வேண்டும். pm.max_children = 5 உடன் இயங்கும் ஒரு சிறிய VPS-ல், ஒரு மெதுவான scheduled job உங்கள் PHP திறனில் ஐந்தில் ஒரு பங்கை எடுத்துக்கொள்ளும். இது உங்கள் தளத்தின் busiest minute-ல் நடப்பதற்கே அதிக வாய்ப்புள்ளது, ஏனெனில் அப்போதுதான் அதிகப்படியான page loads நிகழ்கின்றன.

WordPress நகல்களை (duplicates) கட்டுப்படுத்துகிறது. இது WP_CRON_LOCK_TIMEOUT கால அளவு கொண்ட ஒரு lock-ஐ எடுக்கும் (இயல்பாக 60 seconds). எனவே, ஒரே நேரத்தில் வரும் visitors அனைவரும் தனித்தனியாக வேலையைத் தொடங்க மாட்டார்கள். இந்த lock நகல்களை மட்டுமே தடுக்கும், ஆனால் வேலையை 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-ல் எழுதும். ஒரு நாளைக்கு ஆயிரக்கணக்கான முறை இது நிகழ்ந்தால், அது ஒரு குறிப்பிடத்தக்க சுமை. இதை மற்ற மாற்றங்களுக்கு முன் benchmark a VPS செய்வது போல, கட்டுரைகளில் படிப்பதை விட உங்கள் சொந்த server-ல் அளவிடுவது சிறந்தது.

Caching இந்தச் சூழலை மாற்றும். ஒரு page cache பெரும்பாலான requests-ஐ static HTML ஆக வழங்கினால், அந்த requests-க்கு PHP இயங்காது, எனவே cron சோதனையும் நடக்காது. அதிகப்படியான caching கொண்ட ஒரு busy site, கீழே உள்ள quiet site போலவே செயல்படத் தொடங்கும்.

குறைவான பார்வையாளர்கள் இருக்கும் தளங்களில் cron ஏன் செயல்படுவதில்லை

பார்வையாளர்கள் இல்லை என்றால், cron-ம் இயங்காது. ஒரு நாளைக்குச் சில பார்வையாளர்கள் மட்டுமே வரும் தளங்களில், அந்தப் பார்வையாளர்கள் வரும் சீரற்ற நேரங்களில் மட்டுமே திட்டமிடப்பட்ட பணிகள் (scheduled jobs) இயங்கும்.

இதன் அறிகுறிகள் அனைத்தும் ஒரே மாதிரியானவை. 09:00 மணிக்கு வெளியிடத் திட்டமிடப்பட்ட ஒரு பதிவு, யாராவது ஒரு பக்கத்தை ஏற்றும் வரை Missed schedule என்று குறிக்கப்பட்டு அப்படியே இருக்கும். Backup plugins இரவு நேரப் பணிகளைத் தவிர்க்கும். Update சோதனைகள் தாமதமாவதால், பாதுகாப்பு வெளியீடு (security release) வந்திருந்தாலும், dashboard-ல் எதையும் புதுப்பிக்க வேண்டியதில்லை என்று காட்டும். Order emails, renewal notices மற்றும் expiry warnings ஆகியவை தாமதமாகவே செல்லும்.

இவற்றில் எதற்கும் error log-ல் பதிவுகள் இருக்காது. WordPress-ன் பார்வையில், அந்தப் பணி தொடங்கப்படவே இல்லை என்பதால், அது தாமதமானதாகக் கருதப்படாது.

படி 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. */ என்று தொடங்கும் வரியின் மேலே சேர்க்கவும். ஏனெனில், அந்த comment-க்குக் கீழே உள்ள வரிக்கு wp-settings.php தேவைப்படுகிறது, மேலும் wp-settings.php என்பது WordPress தனது cron check-ஐ init உடன் இணைக்கும் இடமாகும். அந்த require வரியைத் தாண்டிய பிறகு ஒரு constant-ஐ வரையறுத்தால், அது எதையும் மாற்றாது; கோப்பு சரியாகத் தெரிந்தாலும், trigger தொடர்ந்து இயங்கிக்கொண்டே இருக்கும்.

நீங்கள் குறிப்பிட்ட வரியை சரியான இடத்தில் சேர்த்துள்ளீர்களா என்பதை உறுதிப்படுத்தவும்:

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

இந்த constant, நிகழ்வுகள் (events) அட்டவணைப்படுத்தப்படுவதைத் தடுக்காது. முன்னைப் போலவே plugins தொடர்ந்து வேலைகளை (jobs) வரிசையில் (queue) சேர்த்துக்கொண்டே இருக்கும். இது page load-களின் போது அந்த வரிசையை இயக்குவதை மட்டுமே நிறுத்துகிறது. அதாவது, நீங்கள் படி 3-ஐ முடிக்கும் வரை அந்த வரிசை இயங்காது.

இது /wp-cron.php-க்கான நேரடி கோரிக்கைகளைத் (direct requests) தடுக்காது. யார் வேண்டுமானாலும் அந்த URL-ஐக் கோரலாம். பொதுவாக இது பாதிப்பில்லாதது, ஏனெனில் அந்த கோப்பு நிலுவையில் உள்ள வேலைகளை மட்டுமே இயக்கும். உங்கள் web server configuration-ல் இதைத் தடுப்பது விருப்பத்திற்குரியது. நீங்கள் அதைத் தடுத்தால், இந்த வழிகாட்டியின் இறுதியில் உள்ள 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

அதிகாரப்பூர்வ நிறுவல் வழிகாட்டி பரிந்துரைக்கும் 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 பாதை, PHP பதிப்பு மற்றும் WP-CLI பதிப்பு ஆகியவற்றை அச்சிடும். இவை மூன்றையும் காட்டினால், phar சரியாக வேலை செய்கிறது என்று அர்த்தம். ஆகஸ்ட் 2026 நிலவரப்படி, நிறுவல் வழிகாட்டி PHP 7.2.24-ஐ குறைந்தபட்சத் தேவையாகக் குறிப்பிடுகிறது. Ubuntu 24.04-ல் PHP 8.3 இருப்பதால், தற்போதைய server இந்தத் தேவையை விட மேம்பட்ட நிலையில் உள்ளது. பின்னர் sudo wp cli 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-ஐப் பயன்படுத்தப் பரிந்துரைக்கும். இங்கே அதைப் பயன்படுத்த வேண்டாம். இதற்கான காரணம் கீழே உள்ள முதல் தோல்வி முறையில் விளக்கப்பட்டுள்ளது.

மேலும், sudo -u www-data -i வேலை செய்யாது என்பதைக் கவனத்தில் கொள்க. ஏனெனில் அந்த account-ன் login shell /usr/sbin/nologin ஆகும், இதனால் உங்களுக்கு This account is currently not available. என்ற பிழை வரும். கட்டளையை நேரடியாக sudo -u-க்கு அனுப்பும்போது login shell தவிர்க்கப்படுவதால், அது சரியாக இயங்குகிறது.

இப்போது, படி 1-ல் உள்ள constant-ஐ WordPress சரியாகக் கண்டறிகிறதா என்பதை உறுதிப்படுத்தவும்:

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

இது bool(true) என்பதை அச்சிடும். வரையறுக்கப்படாத constant (undefined constant) குறித்த fatal error வந்தால், define() வரியை நிரல் அடையவில்லை என்று பொருள். பொதுவாக, அந்த வரி require கட்டளைக்குக் கீழே அமைந்திருப்பதே இதற்குக் காரணமாகும்.

படி 3: சரியான பயனர் கணக்கில் cron entry-ஐச் சேர்த்தல்

PHP கோப்புகளை எழுதும் உரிமையாளரே இதற்கான சரியான பயனர் ஆவார். இரண்டு முனைகளையும் சரிபார்க்கவும்:

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-வின் இயல்புநிலை நிறுவலில், இரண்டுமே www-data என்று பதிலளிக்கும். Ubuntu 24.04-ல் LAMP stack அமைப்பில் செய்வது போல, ஒரு தளத்திற்குத் தனி PHP-FPM pool மற்றும் தனி பயனர் கணக்கை நீங்கள் உருவாக்கியிருந்தால், கீழே உள்ள அனைத்து இடங்களிலும் அந்தப் பயனரையே பயன்படுத்தவும்.

அந்தப் பயனர் எழுதும் வகையில் ஒரு log directory-ஐ உருவாக்கவும்:

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

அந்தப் பயனரின் crontab-ஐத் திருத்தவும்:

sudo crontab -u www-data -e

ஒரு வரியைச் சேர்க்கவும்:

*/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-ஐப் பயன்படுத்தும்; முந்தைய செயல்பாடு இன்னும் இயங்கிக்கொண்டிருந்தால், இது உடனடியாக நின்றுவிடும். /usr/local/bin/wp என்பது முழுமையான பாதை (absolute path), இது cron-க்கு அவசியம். --path எந்த working directory-யிலிருந்தும் கட்டளையை இயக்க அனுமதிக்கிறது. --due-now வரிசையில் உள்ள அனைத்து நிகழ்வுகளையும் இயக்காமல், நேரம் வந்த நிகழ்வுகளை மட்டும் இயக்கும். இந்த redirect, சாதாரண வெளியீடு மற்றும் பிழைகள் இரண்டையும் நீங்கள் வாசிக்கக்கூடிய ஒரே கோப்பிற்கு அனுப்பும்.

நடைமுறையில் இந்த redirect கட்டாயமானது. Cron ஒரு பணியின் வெளியீட்டை அதன் பயனருக்கு மின்னஞ்சல் செய்யும்; பெரும்பாலான VPS images-ல் mail transfer agent நிறுவப்பட்டிருக்காது, எனவே cron (CRON) info (No MTA installed, discarding output) என்று பதிவு செய்து வெளியீட்டை நீக்கிவிடும். ஒரு கோப்பு ஆதாரத்தைப் பாதுகாப்பாக வைத்திருக்கும்.

சேமிக்கப்பட்ட கோப்பைச் சரிபார்க்கவும்:

sudo crontab -u www-data -l

பல தளங்கள் இருந்தால், ஒவ்வொன்றிற்கும் தனித்தனி வரிகளைப் பயன்படுத்தவும். அவை அனைத்தும் ஒரே நேரத்தில் தொடங்காமல் இருக்க, நிமிடங்களைச் சற்று மாற்றி அமைக்கவும்:

*/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
}

எந்த மாற்றமும் செய்யாமல், அது சரியாகப் பகுப்பாய்வு செய்யப்படுகிறதா எனச் சரிபார்க்கவும்: sudo logrotate --debug /etc/logrotate.d/wp-cron.

படி 4: திட்டமிடப்பட்ட நிகழ்வுகள் உண்மையில் இயங்கினவா என்பதை உறுதிப்படுத்துதல்

ஒரு crontab வரி வெற்றிகரமாகச் சேமிக்கப்பட்டது என்பது எதையும் நிரூபிக்காது. எளிமையான சோதனையிலிருந்து தொடங்கி, உண்மையான நிலையை உறுதிப்படுத்தும் சோதனை வரை செல்லவும்.

முதலில், cron அந்த command-ஐத் தொடங்கியதா? Cron தனது சொந்த unit-ன் கீழ் journal-ல் logs-ஐப் பதிவு செய்கிறது:

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

சரியான நிலையில் உள்ள ஒரு பதிவு இவ்வாறு இருக்கும் (நேரம் மற்றும் 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)

அந்த வரி, cron உங்கள் command-ஐ www-data ஆகத் தொடங்கியது என்பதைக் குறிக்கிறது. அந்த command வேலை செய்ததா இல்லையா என்பதை அது கூறாது.

இரண்டாவதாக, WordPress எதையாவது இயக்கியதா? Log file-ஐப் படிக்கவும்:

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

WP-CLI ஒவ்வொரு நிகழ்விற்கும் ஒரு வரியையும், இறுதியில் மொத்த எண்ணிக்கையையும் அச்சிடும்:

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

பிழைகள் அதே கோப்பில் பதிவாகும், இதுவே 2>&1-ன் முக்கிய நோக்கமாகும். பெரும்பாலான நேரங்களில் இயங்க வேண்டிய நிகழ்வுகள் ஏதும் இருக்காது, எனவே கோப்பில் பெரிய மாற்றம் இருக்காது. எனவே, வேலை காத்திருக்கிறது என்று உங்களுக்குத் தெரிந்த ஒரு run-க்குப் பிறகு கோப்பைப் படிக்கவும்.

மூன்றாவதாக, முழுமையாகச் சோதிக்கவும். ஒரு marker நிகழ்வைத் திட்டமிட்டு, அது மறைவதைக் கவனிக்கவும்:

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

ஒரு கால இடைவெளி வரை காத்திருந்து, மீண்டும் list command-ஐ இயக்கவும். அந்த hook நீக்கப்பட்டிருக்கும், ஏனெனில் ஒருமுறை மட்டும் இயங்கும் நிகழ்வு (one-off event) இயக்கப்பட்டவுடன் queue-விலிருந்து நீக்கப்படும். அந்த hook பெயரில் எந்த plugin-ம் callback-ஐப் பதிவு செய்யாததால், அதை இயக்குவது தளத்தில் வேறு எந்த மாற்றத்தையும் ஏற்படுத்தாது. இரண்டு கால இடைவெளிகளுக்குப் பிறகும் hook பட்டியலில் இருந்தால், queue இயங்கவில்லை என்று அர்த்தம். முதல் இரண்டு சோதனைகள் மூலம் பிரச்சினை cron-ல் உள்ளதா அல்லது WP-CLI-ல் உள்ளதா என்பதை நீங்கள் கண்டறியலாம்.

இதற்கு wp cron test-ஐப் பயன்படுத்த வேண்டாம். அந்த command பார்வையாளர்கள் மூலம் spawning வேலை செய்கிறதா என்று சோதிக்கும், மேலும் DISABLE_WP_CRON true ஆக இருக்கும்போது அது பிழையைக் காட்டும். சரியாக configure செய்யப்பட்ட server-ல் அந்தப் பிழைதான் எதிர்பார்க்கப்படும் output, அது ஒரு கோளாறு அல்ல.

systemd timer மாற்று வழி

இந்த server-ல் ஏற்கனவே திட்டமிடப்பட்ட பணிகள் systemd services and timers மூலம் இயங்கினால், WordPress-ஐயும் அதிலேயே சேர்க்கலாம். ஒவ்வொரு முறையும் இயங்கும் பணி systemctl list-timers-ல் பதிவாகும், மேலும் output ஒரு கோப்பில் சேமிக்கப்படுவதற்குப் பதிலாக journal-க்குச் செல்லும், எனவே நீங்கள் கோப்புகளை rotate செய்ய வேண்டியதில்லை.

/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-ன் இரண்டு பிரதிகளை இயக்காது, எனவே இந்த முறைக்கு flock தேவையில்லை. Persistent=true, கணினி அணைக்கப்பட்டிருந்தபோது விடுபட்ட பணியை மீண்டும் இயக்க உதவுகிறது, இது crontab entry-ஆல் செய்ய முடியாது.

Crontab அல்லது timer இரண்டில் ஒன்றை மட்டும் தேர்ந்தெடுக்கவும். ஒரே தளத்திற்கு இரண்டையும் இயக்கினால், queue இரண்டு முறை கையாளப்படும்; இதனால் மின்னஞ்சல் அல்லது order job போன்ற பணிகள் இரண்டு முறை இயங்குவது உங்கள் வாடிக்கையாளர்களுக்குத் தெரியும்.

cron job ஏன் root பயனர் மூலம் இயங்கக்கூடாது

இந்த அமைப்பு தோல்வியடைவதற்கான மூன்று வழிகளில் இது முதலாவது. இந்த job-ஐ root-ன் crontab-ல் சேர்த்தால், WP-CLI எதையும் செய்வதற்கு முன்பே நின்றுவிடும்:

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

Queue ஒருபோதும் இயங்காது. நீங்கள் output-ஐ redirect செய்யவில்லை என்றால், அந்தச் செய்தியை உங்களால் பார்க்க முடியாது. இதற்குச் செய்யப்படும் ஆபத்தான தீர்வு --allow-root-ஐச் சேர்ப்பதாகும். ஏனெனில், அந்த run-ன் போது plugin உருவாக்கும் ஒவ்வொரு கோப்பும் root-க்குச் சொந்தமாகிவிடும். அடுத்த web request www-data பயனர் மூலம் இயங்கும்போது, அந்த directories-ல் கோப்புகளை எழுத முடியாது. அப்போது தளம் இது போன்ற பிழைகளைக் காட்டும்:

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 ஆகியவை தனித்தனி கோப்புகள். எனவே, ஒன்றிலிருந்து வரியை நீக்குவது மற்றொன்றைப் பாதிக்காது. இரண்டையும் சரிபார்க்கவும்:

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

cron ஏன் wp: not found பிழையைத் தெரிவிக்கிறது

இது இரண்டாவது தோல்வி. Cron தனது பயனர் பணிகளுக்கு மிகக் குறுகிய PATH-ஐ மட்டுமே வழங்குகிறது, அது /usr/bin:/bin ஆகும். WP-CLI /usr/local/bin-ல் நிறுவப்படுகிறது, இது அந்தப் பட்டியலில் இல்லை. பணி தொடங்குகிறது, ஒரு நொடியின் ஒரு பகுதியில் தோல்வியடைகிறது, மேலும் பதிவில் ஒரு வரி மட்டுமே உள்ளது:

/bin/sh: 1: wp: not found

ஊகிப்பதற்குப் பதிலாக, cron-ன் சூழலை நீங்களே பாருங்கள். ஒரு தற்காலிக வரியைச் சேர்க்கவும்:

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

ஒரு இடைவெளிக்குப் பிறகு /tmp/cron-env.txt-ஐப் படியுங்கள், பின்னர் அந்த வரியை நீக்கவும். அந்த கோப்பில் உள்ள PATH= மதிப்புதான் உங்கள் பணிக்குக் கிடைக்கும் துல்லியமான சூழலாகும்.

இதற்கு இரண்டு தீர்வுகள் உள்ளன. படி 3-ல் உள்ளவாறு /usr/local/bin/wp என்ற முழுமையான பாதையைப் (absolute path) பயன்படுத்தவும். அல்லது crontab-ன் மேற்புறத்தில், அனைத்துப் பணி வரிகளுக்கும் மேலே 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-ல் நிகழும்), உங்களுக்குக் கிடைக்கும் பிழை:

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

அத்தகைய சூழலில், interpreter-ஐ நேரடியாக அழைக்கவும், உதாரணமாக /usr/local/bin/php /usr/local/bin/wp --path=/srv/www/example.com cron event run --due-now.

ஒரு நிமிட இடைவெளி ஏன் பழைய சிக்கலை மீண்டும் உருவாக்குகிறது

இது மூன்றாவது தோல்வியாகும். * * * * * ஐந்து நிமிடங்களை விட பாதுகாப்பானது என்று தோன்றலாம், ஆனால் அதிக போக்குவரத்து கொண்ட தளத்தில் இது உங்களை மீண்டும் பழைய நிலைக்குக் கொண்டு செல்லும். ஒரு செயல்முறை (run) இடைவெளியை விட அதிக நேரம் எடுத்தால், முதல் செயல்முறை முடிவதற்கு முன்பே அடுத்தது தொடங்கிவிடும். பத்து நிமிடங்களுக்குப் பிறகு, பத்து PHP செயல்முறைகள் இயங்கிக் கொண்டிருக்கும்; ஒவ்வொன்றும் அதன் சொந்த நினைவகத்தையும் (memory) தரவுத்தள இணைப்பையும் (database connection) வைத்திருக்கும்.

செயல்முறைகள் குவிந்துள்ளதா என்பதை நேரடியாகச் சரிபார்க்கவும்:

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

etimes என்பது வினாடிகளில் கணக்கிடப்படும் செயல்முறையின் வயது ஆகும். ஒரே ஒரு வரி இருந்தால் அது ஆரோக்கியமான நிலை. உங்கள் இடைவெளியை விட அதிக வயதுடைய பல வரிகள் இருந்தால், செயல்முறைகள் ஒன்றன் மேல் ஒன்றாக அடுக்கப்படுகின்றன என்று அர்த்தம். சிறிய VPS-ல் இது MySQL Too many connections பிழையாக முடியும், அல்லது நினைவகத்தை மீட்டெடுக்க kernel-ஆல் PHP செயல்முறை நிறுத்தப்படும். இதை sudo dmesg -T | grep -i 'killed process' மூலம் நீங்கள் உறுதிப்படுத்தலாம்.

WP-CLI, wp-cron.php-க்கு கோரிக்கை விடுப்பதற்குப் பதிலாக, நிகழ்வு அழைப்புகளை (event callbacks) நேரடியாக இயக்குகிறது. எனவே, நகல் உருவாக்கங்களைத் தடுக்க WordPress பயன்படுத்தும் 60 வினாடி பூட்டு (lock) இங்கு பொருந்தாது. படி 3-ல் உள்ள flock -n தான் இப்போது ஒன்றன் மேல் ஒன்றாக இயங்குவதைத் தடுக்கிறது. தவிர்க்கப்பட்ட ஒரு செயல்முறை, வடிவமைப்பின்படி, உடனடியாகவும் அமைதியாகவும் வெளியேறிவிடும். ஒன்றன் மேல் ஒன்றாக இயங்குவது என்பது crontab-ல் நீங்கள் தீர்க்க வேண்டிய சிக்கல்; இதை host kernel உங்களுக்காகத் தீர்க்காது. Linux kernel 7.2-ல் சேர்க்கப்பட்ட cache aware task placement கூட ஒரு செயல்முறை எந்த core-ல் இயங்க வேண்டும் என்பதை மட்டுமே தீர்மானிக்கிறது, எத்தனை செயல்முறைகளை நீங்கள் தொடங்கினீர்கள் என்பதை அது கட்டுப்படுத்துவதில்லை.

நீங்கள் சார்ந்திருக்கும் மிகக் குறுகிய கால அட்டவணைக்கு ஏற்ப இடைவெளியைத் தேர்வு செய்யவும். முதலில் ஒரு செயல்முறை எவ்வளவு நேரம் எடுக்கிறது என்பதை அளவிடவும்:

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

ஐந்து நிமிடங்கள் என்பது ஒரு நியாயமான இயல்புநிலை (default) ஆகும்: 09:00 மணிக்குத் திட்டமிடப்பட்ட ஒரு பதிவு 09:05-க்குள் வெளியாகும். காலக்கெடு முக்கியமில்லாத தளங்களுக்கு பதினைந்து நிமிடங்கள் போதுமானது. ஒரு நிமிடம் என்பது கடைகளுக்கும், வரிசை சார்ந்த (queue driven) plugins-க்கும் மட்டுமே தேவைப்படும். ஒரு செயல்முறை சில வினாடிகளில் முடிவடையும் என்று உங்களுக்குத் தெரிந்தால் மட்டுமே இதைப் பயன்படுத்தவும்.

WP-CLI-ஐ நிறுவ முடியாவிட்டால்

சில ஹோஸ்டிங் நிறுவனங்கள் shell கருவிகளைத் தடுக்கும். wp-cron.php-க்கு ஒரு சாதாரண HTTP கோரிக்கையை அனுப்புவதன் மூலம், முழு web stack வழியாக அதே வரிசையை (queue) இயக்க முடியும்:

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

இதன் மூலம் நீங்கள் இழப்பவை:

• இந்த இயக்கம் web server மற்றும் PHP-FPM கோரிக்கை காலாவதி நேரத்தால் (timeouts) கட்டுப்படுத்தப்படும், எனவே நீண்ட நேரம் எடுக்கும் பணிகள் பாதியிலேயே நிறுத்தப்படலாம்.
• சான்றிதழ் செல்லுபடியாக இருக்க வேண்டும், இல்லையெனில் curl ஆனது SSL certificate problem பிழையுடன் நின்றுவிடும். எனவே Certbot on nginx மூலம் சான்றிதழ் புதுப்பித்தல் சரியாக நடப்பதை உறுதி செய்யவும்.
• Page caching மூலம் wp-cron.php-ஐ cache செய்யக்கூடாது, இல்லையெனில் cron கோரிக்கைகள் cache செய்யப்பட்ட பதிலையே பெறும், எந்தப் பணியும் இயங்காது.
• ஒவ்வொரு நிகழ்வுக்கும் வெளியீடு (output) கிடைக்காது, எனவே ஒரு பணி இயங்கியதற்கான ஒரே ஆதாரம் அதன் விளைவு மட்டுமே.

-sS என்பது வெற்றிகரமாக இயங்கும்போது curl-ன் வெளியீட்டை அமைதிப்படுத்தும், அதே சமயம் பிழைகளை மட்டும் காட்டும். இது ஒரு cron job-க்குத் தேவையான அமைப்பாகும்.

server-ன் அட்டவணையில் வேறு என்னென்ன இருக்க வேண்டும்

WordPress queue-வை system cron நிர்வகிக்கத் தொடங்கிய பிறகு, server-ன் பிற வழக்கமான பணிகளையும் அங்கேயே வைத்து நிர்வகிப்பது எளிது. Operating system security patches-ஐ நீங்களே கைமுறையாக cron-ல் எழுதுவதற்குப் பதிலாக, unattended upgrades மூலம் கையாளுவது சிறந்தது. WordPress plugin மற்றும் theme updates-ஐப் பொறுத்தவரை, இது வேறுபட்ட அணுகுமுறையைக் கோருகிறது: crontab-ல் உள்ள wp plugin update --all கட்டளை, அதிகாலை 3 மணிக்கு யாருடைய கண்காணிப்பும் இல்லாத நேரத்தில் நேரடி இணையதளத்தை (live site) செயலிழக்கச் செய்யக்கூடும். எனவே, இத்தகைய பணிகளைத் திட்டமிட்டுச் செய்யவும் அல்லது staging மற்றும் backup நடைமுறைகளுக்குப் பிறகு மேற்கொள்ளவும்.

FAQ

WP-Cron-ஐ முடக்குவது திட்டமிடப்பட்ட பதிவுகள் (scheduled posts) வெளியாவதைத் தடுக்குமா?

இல்லை, வரிசையை (queue) இயக்க வேறு ஏதேனும் வழி இருந்தால் பதிவுகள் வெளியாகும். DISABLE_WP_CRON என்பது பக்கங்கள் ஏற்றப்படும்போது வரிசையைத் தூண்டுவதை மட்டுமே நிறுத்துகிறது. நிகழ்வுகள் முன்பைப் போலவே திட்டமிடப்படும். 09:00 மணிக்கு வெளியிடப்பட வேண்டிய ஒரு பதிவு, 09:00 மணிக்குப்பிறகு நடக்கும் முதல் cron இயக்கத்தின்போது வெளியாகும்; எனவே ஐந்து நிமிட இடைவெளியில் அது 09:05-க்குள் வெளியாகிவிடும். நீங்கள் அந்த constant-ஐ அமைத்துவிட்டு, cron entry-ஐச் சேர்க்கவில்லை என்றால், வரிசையை இயக்கும் வரை அந்தப் பதிவு Missed schedule எனக் குறிக்கப்பட்டு பட்டியலிலேயே இருக்கும்.

WordPress cron job-ஐ எந்த user இயக்க வேண்டும்?

PHP கோப்புகளை எழுதும் உரிமை கொண்ட user-ஐப் பயன்படுத்த வேண்டும்; Ubuntu-வின் இயல்புநிலை நிறுவலில் இது www-data ஆகும். stat -c '%U %G' /srv/www/example.com/wp-content/uploads மூலம் இதைச் சரிபார்த்து, உங்கள் PHP-FPM pool config-ல் உள்ள user = வரியுடன் ஒப்பிட்டுப் பார்க்கவும். root user-ஆக இந்த job-ஐ இயக்கினால் WP-CLI ஒரு YIKES பிழையுடன் நின்றுவிடும். மேலும், --allow-root மூலம் கட்டாயப்படுத்தி இயக்கினால், wp-content-க்குள் root உரிமையுள்ள கோப்புகள் உருவாகிவிடும்; அதன் பிறகு web server-ஆல் அவற்றை எழுத முடியாது.

System cron எவ்வளவு அடிக்கடி WordPress cron-ஐ இயக்க வேண்டும்?

பெரும்பாலான தளங்களுக்கு ஐந்து நிமிடங்களுக்கு ஒருமுறை என்பது பொருத்தமானது. நீங்கள் நம்பியிருக்கும் மிகக் குறுகிய கால அட்டவணைக்கு ஏற்ப இந்த இடைவெளியை அமைக்கவும். ஒருமுறை இயங்குவதற்கு எடுக்கும் நேரத்தை விட இது அதிகமாக இருக்க வேண்டும்; WP-CLI கட்டளைக்கு முன்னால் time-ஐச் சேர்ப்பதன் மூலம் இந்த நேரத்தை நீங்கள் அளவிடலாம். ஒரு நிமிட இடைவெளியில் அமைத்தால், அதிக traffic உள்ள தளங்களில் flock மூலம் தடுக்கப்படாவிட்டால், இயக்கங்கள் ஒன்றன் மேல் ஒன்றாக அடுக்கப்படும்.

WP-Cron-ஐ முடக்கிய பிறகு ஏன் wp cron test தோல்வியடைகிறது?

ஏனெனில், அந்த கட்டளை பார்வையாளர்களால் தூண்டப்படும் செயல்பாட்டைச் சோதிக்கிறது, மேலும் DISABLE_WP_CRON என்பது true என அமைக்கப்பட்டிருக்கும்போது அது பிழையைக் காட்டுகிறது. இந்த முறையில் கட்டமைக்கப்பட்ட server-க்கு இதுவே சரியான முடிவு. அதற்குப் பதிலாக system cron பாதையைச் சரிபார்க்கவும்: /var/log/wp-cron/example.log-ஐப் படிக்கவும், அல்லது wp cron event schedule மூலம் ஒரு marker நிகழ்வைத் திட்டமிட்டு, அடுத்த இயக்கத்திற்குப் பிறகு அது wp cron event list-லிருந்து மறைந்துவிட்டதா என்பதை உறுதிப்படுத்தவும்.

எனக்கு WP-CLI தேவையா, அல்லது wp-cron.php-க்கு curl பயன்படுத்தினால் போதுமா?

Curl வேலை செய்யும், WP-CLI-ஐ நிறுவ முடியாத சூழலில் இதுவே சரியான தீர்வாகும். இது web server வழியாக WordPress-ஐ ஏற்றுவதால் மெதுவாக இருக்கும், மேலும் request timeout-ஆல் கட்டுப்படுத்தப்படும். WP-CLI நிகழ்வுகளை web timeout இல்லாத command line PHP process-ல் இயக்குகிறது. இது ஒவ்வொரு நிகழ்விற்கும் அதன் கால அளவுடன் ஒரு வரியை அச்சிடுவதால், எவை இயங்கின மற்றும் எவ்வளவு நேரம் எடுத்தன என்பதை log மூலம் துல்லியமாக அறியலாம்.