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-ஆக இயங்க வேண்டும், திட்டமிடப்பட்ட நிகழ்வுகள் உண்மையில் நடந்தனவா என்பதை எப்படி உறுதிப்படுத்துவது, மற்றும் தளத்தில் எந்த பிழைச் செய்தியும் காட்டாமல் இந்த அமைப்பு தோல்வியடையும் மூன்று வழிகள் ஆகியவை இதில் அடங்கும்.

இந்த உதாரணங்கள் WordPress கோப்பகத்திற்கு /srv/www/example.com-ஐயும், web server user-க்கு www-data-ஐயும் பயன்படுத்துகின்றன. எல்லா இடங்களிலும் உங்கள் சொந்த 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 வினாடிகள்). எனவே, ஒரே நேரத்தில் வரும் 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-ல் எழுதும். ஒரு நாளைக்கு ஆயிரக்கணக்கில் இது நிகழ்ந்தால், அது ஒரு உண்மையான சுமை. இதை ஒரு கட்டுரையில் படிப்பதற்குப் பதிலாக, உங்கள் சொந்த server-ல் அளவிடுவது சிறந்தது. benchmark a VPS செய்வது போல, எந்தவொரு மாற்றத்திற்கு முன்பும் பின்பும் இதைச் சரிபார்க்கவும்.

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-ல் எதையும் காட்டாது. ஆர்டர் மின்னஞ்சல்கள், புதுப்பித்தல் அறிவிப்புகள் மற்றும் காலாவதி எச்சரிக்கைகள் தாமதமாகவே செல்லும்.

இவற்றில் எதற்கும் பிழைப் பதிவுகள் (error logs) இருக்காது. 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 தொடர்ந்து பணிகளை வரிசையில் (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) என்பதைத் திரையில் காட்டும். ஒருவேளை 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 என்பது முழுமையான 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

சரியாக இயங்கும் ஒரு entry இப்படித்தான் இருக்கும் (நேரம் மற்றும் 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-ல் அந்தப் பிழை வருவதுதான் எதிர்பார்க்கப்படும் முடிவு, அது ஒரு கோளாறு அல்ல.

systemd timer மாற்று வழி

இந்த server-ன் பிற திட்டமிடப்பட்ட பணிகள் ஏற்கனவே systemd services and timers மூலம் இயங்கினால், WordPress-ஐயும் அதில் சேர்க்கவும். ஒவ்வொரு முறையும் இயங்கும் பணி systemctl list-timers-ல் பதிவாகும், மேலும் அதன் வெளியீடு (output) நீங்கள் rotate செய்ய வேண்டிய கோப்பிற்குப் பதிலாக 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-ன் இரண்டு பிரதிகளை இயக்காது, எனவே இந்த முறைக்கு flock தேவையில்லை. கணினி அணைக்கப்பட்டிருந்தபோது விடுபட்ட பணியை, Persistent=true தானாகவே ஈடுசெய்து இயக்கும்; இது crontab-ல் சாத்தியமில்லை.

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

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

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

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

வரிசை (queue) ஒருபோதும் இயங்காது. நீங்கள் output-ஐ redirect செய்யவில்லை என்றால், இந்தச் செய்தியை உங்களால் பார்க்க முடியாது. --allow-root-ஐச் சேர்ப்பது ஆபத்தான தீர்வாகும், ஏனெனில் அந்த இயக்கத்தின் போது 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) சரிசெய்துவிட்டு, வேலையை நகர்த்தவும்:

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-ல் நிறுவப்படுகிறது, இது அந்தப் பட்டியலில் இல்லை. பணி தொடங்குகிறது, ஒரு நொடியின் ஒரு பகுதியில் தோல்வியடைகிறது, மேலும் பதிவில் (log) ஒரு வரி மட்டுமே இருக்கும்:

/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-ஐப் பயன்படுத்தவும். அல்லது 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.

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

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

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

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

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

WP-CLI, wp-cron.php-க்கு கோரிக்கை அனுப்புவதற்குப் பதிலாக event callback-களை நேரடியாக இயக்குகிறது. எனவே, நகல் உருவாக்கத்தைத் தடுக்க WordPress பயன்படுத்தும் 60 வினாடி lock முறை இங்கு பொருந்தாது. படி 3-ல் உள்ள flock -n தான் இப்போது ஒன்றன் மேல் ஒன்றாக இயங்குவதைத் தடுக்கிறது. தவிர்க்கப்பட்ட ஒரு run, வடிவமைப்பின்படி எந்த அறிவிப்பும் இன்றி உடனடியாக வெளியேறிவிடும்.

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

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-ஐ அடிப்படையாகக் கொண்ட plugin-களுக்கும் மட்டுமே தேவைப்படும். ஒரு run சில வினாடிகளில் முடிவடையும் என்று தெரிந்தால் மட்டுமே இதைப் பயன்படுத்தவும்.

WP-CLI-ஐ உங்களால் நிறுவ முடியாவிட்டால்

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

*/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 செய்யப்பட்ட பதிலையே பெறும், எந்தப் பணியும் இயங்காது.
• நிகழ்வு வாரியான வெளியீடு (per event 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 மணிக்கு யாரும் கவனிக்காத நேரத்தில் நேரலையில் உள்ள தளத்தை முடக்கக்கூடும். எனவே, அத்தகைய பணிகளைத் திட்டமிட்டுச் செய்யவும் அல்லது staging மற்றும் backup நிலைகளுக்குப் பிறகு மேற்கொள்ளவும்.

FAQ

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

இல்லை, வரிசையை (queue) இயக்க வேறு ஏதேனும் வழி இருந்தால் பதிவுகள் வெளியாகும். DISABLE_WP_CRON என்பது பக்கங்கள் ஏற்றப்படும்போது வரிசையைத் தூண்டுவதை மட்டுமே நிறுத்துகிறது. நிகழ்வுகள் முன்பைப் போலவே துல்லியமாகத் திட்டமிடப்படும். 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-ஐச் சேர்ப்பதன் மூலம் இந்த நேரத்தை நீங்கள் அளவிடலாம். ஒரு நிமிட இடைவெளி என்பது, 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 மூலம் துல்லியமாக அறியலாம்.