Cum programați sarcini cron (cron jobs) în cPanel

Cum programați sarcini cron (cron jobs) în cPanel, adică cum faceți serverul să ruleze singur, la ore fixe, ce altfel ați face manual sau ați lăsa pe seama vizitatorilor: copii de siguranță, curățări, actualizări, generarea hărții site-ului, sarcinile programate ale aplicației. Interfața din cPanel scrie pentru dumneavoastră linia de crontab; ce rămâne de înțeles este sintaxa intervalului și cum se scrie o comandă care rulează corect fără terminal deschis.

Ghidul acoperă interfața, sintaxa, exemplele pe care le folosim pe conturile clienților, verificarea rulării, erorile frecvente și limitele găzduirii partajate.

Cum programați sarcini cron (cron jobs) în cPanel

Interfața

Advanced, Cron Jobs. Pagina are trei părți: adresa de e-mail pentru notificări (primește ieșirea fiecărei rulări; puneți o adresă citită sau lăsați goală și redirecționați ieșirea în jurnal), formularul Add New Cron Job cu intervalele predefinite și cele cinci câmpuri, și lista Current Cron Jobs, cu editare și ștergere. Intervalele predefinite (la fiecare minut, la 5 minute, la oră, zilnic, săptămânal, lunar) acoperă majoritatea cazurilor; pentru altele, completați câmpurile.

Sintaxa celor cinci câmpuri

minut  oră  zi-din-lună  lună  zi-din-săptămână  comanda
*/15   *    *            *     *                 la fiecare 15 minute
0      3    *            *     *                 zilnic la 3:00
30     2    *            *     1                 lunea la 2:30
0      6    1            *     *                 pe 1 ale lunii la 6:00
0      */6  *            *     *                 la fiecare 6 ore

Steluța înseamnă „orice valoare”; */n înseamnă „la fiecare n”; listele (1,15) și intervalele (1-5) sunt acceptate. Ziua din săptămână merge de la 0 (duminică) la 6. Ora este cea a serverului; verificați fusul (comanda date din terminal) înainte să programați „la 3 noaptea”.

Cum scrieți comanda

Cron rulează comanda fără mediul terminalului: fără PATH complet, fără dosar curent cunoscut. De aici, trei reguli: căi absolute (spre script și spre interpretor), dosar explicit (cd înainte de comandă) și ieșirea redirecționată (în jurnal sau în /dev/null), ca să nu primiți un e-mail la fiecare rulare.

Script PHP

/usr/local/bin/php -q /home/contul/public_html/scripturi/curatare.php >> /home/contul/jurnale/curatare.log 2>&1

Calea spre php diferă pe versiuni; pe cPanel, versiunea contului este de obicei la /usr/local/bin/php, iar versiunile specifice la /opt/cpanel/ea-php83/root/usr/bin/php. Folosiți-o pe cea a site-ului, ca scriptul să ruleze cu aceleași extensii.

Adresă web (pentru aplicații care își expun cron-ul ca pagină)

/usr/bin/curl -s -o /dev/null "https://www.exemplu.ro/cron.php?cheie=SECRET"
/usr/bin/wget -q -O /dev/null "https://www.exemplu.ro/cron.php?cheie=SECRET"

Cheia din adresă împiedică rularea de către oricine găsește adresa; fără ea, oricine poate declanșa sarcina.

Comenzi shell

cd /home/contul/public_html && /usr/local/bin/wp cron event run --due-now >> /home/contul/jurnale/wp-cron.log 2>&1

Exemple pe care le folosim

WordPress: cron-ul intern mutat în cron real

WordPress își rulează sarcinile programate (publicări, copii, verificări de actualizări) la vizitele utilizatorilor, prin wp-cron.php, ceea ce încetinește vizitele și nu rulează deloc când nu are vizite. Dezactivați-l în wp-config.php (define('DISABLE_WP_CRON', true);) și programați-l din cPanel la fiecare 15 minute:

*/15 * * * * cd /home/contul/public_html && /usr/local/bin/wp cron event run --due-now >/dev/null 2>&1

Fără WP-CLI, comanda este curl spre wp-cron.php?doing_wp_cron. Comenzile WP-CLI utile în cron sunt în ghidul despre terminalul cPanel și WP-CLI.

Copie de siguranță zilnică

15 3 * * * cd /home/contul && /usr/local/bin/wp --path=public_html db export backup/baza-$(date +\%F).sql.gz 2>/dev/null; tar -czf backup/fisiere-$(date +\%F).tar.gz -C public_html --exclude='wp-content/cache' wp-content wp-config.php; find backup -type f -mtime +14 -delete

Atenție la semnul procent: în crontab, % are înțeles special și trebuie scris \% (interfața cPanel îl acceptă ca atare, dar verificați în listă). Dosarul backup este în afara public_html. Strategia completă este în ghidul despre copiile de siguranță automate în cPanel.

Curățări

0 4 * * 0 find /home/contul/public_html/wp-content/cache -type f -mtime +7 -delete
0 5 1 * * cd /home/contul/public_html && /usr/local/bin/wp transient delete --expired && /usr/local/bin/wp db optimize >/dev/null 2>&1

Verificări de securitate

0 6 * * 1 cd /home/contul/public_html && /usr/local/bin/wp core verify-checksums 2>&1 | grep -v "Success" | mail -s "Verificare WP $(hostname)" admin@firma.ro

Trimite e-mail doar când există diferențe; verificarea este cea din ghidul despre detectarea malware-ului.

Verificarea rulării

cPanel nu are un jurnal al cron-ului vizibil utilizatorului. Metodele: redirecționarea ieșirii în propriul jurnal (ca mai sus) și verificarea lui; e-mailul de notificare, pentru sarcinile rare; un fișier-martor pe care scriptul îl atinge la final (touch /home/contul/jurnale/ultima-rulare) și a cărui dată o verificați; sau, pentru copii, existența fișierului cu data de azi. Un cron care „nu rulează” este aproape întotdeauna unul care rulează și eșuează tăcut, fiindcă ieșirea merge în /dev/null; puneți-o temporar într-un jurnal și citiți eroarea.

Erori frecvente

• Comandă care merge în terminal, dar nu în cron: PATH-ul; puneți căi absolute la php, wp, curl, mysql.
• Scriptul rulează în alt dosar: cd explicit înainte sau --path la WP-CLI.
• Permisiuni: scriptul nu are drept de execuție (chmod 700) sau dosarul de jurnal nu există.
• Semnul % neescapat: comanda se trunchiază la primul %.
• Două rulări suprapuse (o copie de 20 de minute programată la 15 minute): folosiți flock -n /home/contul/lock comanda, ca a doua rulare să renunțe dacă prima nu s-a terminat.
• Versiunea PHP a cron-ului diferă de a site-ului: extensii lipsă, erori ciudate; folosiți calea spre versiunea corectă.
• E-mailuri la fiecare rulare: redirecționați ieșirea sau lăsați adresa goală.

Exemplu: generarea hărții site-ului și notificarea

Pe un site construit la comandă, harta XML se regenerează dintr-un script PHP care citește paginile publicate și scrie fișierul în docroot; programată zilnic la 4:00, după publicările de peste zi, cu lastmod real. Același script poate trimite apoi harta spre un serviciu de indexare (IndexNow pentru Bing) și poate verifica, cu curl, că harta răspunde 200. Un cron de acest tip este mai sigur decât generarea la cerere, care încarcă serverul la fiecare accesare a hărții de către roboți; ce trebuie să conțină harta este în ghidul despre trimiterea hărții XML.

Exemplu: monitorizare simplă

*/5 * * * * /usr/bin/curl -s -o /dev/null -w "%{http_code}" https://www.exemplu.ro/ | grep -q 200 || echo "site picat $(date)" | mail -s "ALERTĂ exemplu.ro" admin@firma.ro

La fiecare cinci minute, cere prima pagină și trimite e-mail dacă nu răspunde 200. Rulat de pe un alt cont sau server decât cel monitorizat, altfel pică odată cu site-ul. Este o monitorizare minimă, gratuită, suficientă pentru site-uri mici; pentru mai mult, un serviciu extern cu verificări din mai multe locații.

Limitele pe găzduirea partajată

Sarcinile cron consumă din resursele contului (procesor, procese, I/O), iar limitele se aplică și lor; o copie de siguranță în orele de vârf atinge limita de I/O și încetinește site-ul, cum arătăm în ghidul despre monitorizarea resurselor. Unii furnizori interzic intervalele sub 5 sau 15 minute și limitează numărul de sarcini; verificați termenii. Sarcinile lungi se programează noaptea și se limitează cu nice și ionice, dacă sunt disponibile. Pe un server propriu, aceleași reguli se aplică în crontab-ul utilizatorului, cu jurnalul de sistem la dispoziție, după modelul din ghidul despre copiile de siguranță cu cron și rsync.

Sarcinile programate și SEO

Trei sarcini cron au efect direct asupra vizibilității: regenerarea hărții site-ului cu lastmod corect, curățarea cache-ului de pagini după publicări (ca Google să vadă versiunea nouă) și verificarea săptămânală a paginilor principale (cod 200, fără noindex), cu alertă pe e-mail când ceva s-a schimbat. Am prins astfel, pe site-urile clienților, un noindex apărut după o actualizare de modul și o redirecționare în buclă după o migrare, înainte ca Search Console să le raporteze. Un script de zece rânduri cu curl și grep, rulat luni dimineața, este cea mai ieftină asigurare pentru indexare; ce verifică exact este descris în ghidul despre erorile de indexare frecvente.

Cazuri avansate

Intervale neregulate (a doua și a patra luni din lună, ultima zi a lunii), sarcini care depind una de alta, sarcini care rulează doar dacă un fișier există: toate se rezolvă cu un script shell care conține logica și cu un cron simplu care îl apelează; exemplele sunt în ghidul despre cronurile avansate pentru sarcini repetitive. Pentru sarcini care trebuie să ruleze exact la secundă sau de mai multe ori pe minut, cron nu este unealta; folosiți un proces permanent (o coadă de sarcini a aplicației), pe un server unde îl puteți rula.

Lista de verificare pentru o sarcină nouă

1. Comanda testată manual din terminal, cu aceleași căi absolute.
2. Ieșirea redirecționată în jurnal; e-mail doar pentru erori.
3. Interval potrivit cu durata (cu flock dacă se pot suprapune) și cu limitele contului.
4. Ora în fusul serverului, în afara vârfului de trafic.
5. Verificare a doua zi: jurnalul are rândurile așteptate, fișierele există.
6. Notă în inventarul contului: ce face sarcina, cine a pus-o, când.

Surse

• Documentația cPanel, sarcini cron: interfața, câmpurile și notificările.
• Documentația cPanel: secțiunea Advanced și uneltele înrudite.