Cum folosiți cronuri avansate pentru sarcini repetitive în cPanel

Cum folosiți cronuri avansate pentru sarcini repetitive în cPanel este întrebarea care apare când site-ul are nevoie de ceva făcut la ore fixe, fără să stea cineva la calculator: o copie de siguranță noaptea, un import de prețuri dimineața, curățarea fișierelor temporare o dată pe săptămână. Interfața Cron Jobs din cPanel programează exact asta, iar partea de cronuri avansate înseamnă să scrieți singur intervalul, în loc să alegeți dintr-o listă, și să vă asigurați că sarcina rulează corect și lasă urme.

Ghidul de mai jos pornește de la sintaxă, trece prin exemple folosite pe site-uri reale și se încheie cu ce verificați când un cron nu face ce trebuie.

Cum folosiți cronuri avansate pentru sarcini repetitive în cPanel

Un cron este o linie într-un tabel de pe server: cinci câmpuri care spun când, urmate de comanda care spune ce. Serverul citește tabelul în fiecare minut și pornește comenzile al căror moment a venit.

În cPanel, tabelul se administrează din Advanced, Cron Jobs, fără acces la terminal. Fiecare rând adăugat acolo ajunge în tabelul de cron al utilizatorului contului.

Cele cinci câmpuri

• Minute: 0 până la 59.
• Hour: 0 până la 23, ora serverului, nu ora dvs. Verificați fusul orar al serverului în cPanel, în bara laterală, sau cu un cron de test care scrie data.
• Day: 1 până la 31, ziua din lună.
• Month: 1 până la 12.
• Weekday: 0 până la 6, unde 0 este duminica; 7 este acceptat și el ca duminică.

Asteriscul înseamnă „orice valoare”. Pe lângă valori simple, câmpurile acceptă liste, 1,15, intervale, 9-17, și pași, */10. Combinațiile dau precizia de care aveți nevoie.

Exemple de intervale

*/15 * * * *      la fiecare 15 minute
0 * * * *         la fiecare oră fixă
30 3 * * *        zilnic la 03:30
0 9-18 * * 1-5    la fiecare oră fixă între 9 și 18, de luni până vineri
0 2 * * 0         duminica la 02:00
0 4 1 * *         în prima zi a lunii la 04:00
0 0 1 1 *         o dată pe an, la 1 ianuarie

Un interval greșit des întâlnit este * 3 * * *, cu intenția „zilnic la ora 3”. El rulează comanda în fiecare minut între 03:00 și 03:59, de 60 de ori. Minutul se scrie explicit: 0 3 * * *.

Comanda: căi absolute și ieșire redirecționată

Cronul rulează într-un mediu minimal, fără variabilele de sistem din terminalul obișnuit. Comanda care merge când o tastați poate pica din cron doar fiindcă nu găsește programul. Regula: căi absolute peste tot.

/usr/local/bin/php /home/utilizator/public_html/script.php >> /home/utilizator/logs/script.log 2>&1

Partea de la >> încolo trimite tot ce scrie scriptul, inclusiv erorile, într-un fișier de jurnal. Fără ea, ieșirea ajunge într-un e-mail la fiecare rulare sau se pierde. Calea către PHP o aflați din cPanel, la MultiPHP Manager, sau din terminal cu which php; pe serverele cu mai multe versiuni, folosiți calea versiunii pe care rulează site-ul, de exemplu /opt/cpanel/ea-php84/root/usr/bin/php.

Scripturi care trebuie apelate prin adresa web

Unele aplicații își expun sarcinile printr-o adresă, nu printr-un fișier. Atunci comanda cere adresa:

/usr/bin/curl -s -o /dev/null https://firma.ro/cron/rulare?cheie=secret

Opțiunea -s ține curl tăcut, iar -o /dev/null aruncă răspunsul. Cheia din adresă împiedică pe oricine altcineva să declanșeze sarcina.

Exemple din practică

WordPress: cronul intern mutat pe cron real

WordPress își rulează sarcinile programate, publicări, actualizări, e-mailuri, doar când cineva vizitează site-ul. Pe un site cu trafic mic, articolul programat la 9:00 apare la 11:40, când intră primul vizitator. Soluția este dezactivarea mecanismului intern și un cron real la fiecare cinci minute:

*/5 * * * * /usr/local/bin/php /home/utilizator/public_html/wp-cron.php >> /home/utilizator/logs/wp-cron.log 2>&1

În wp-config.php adăugați define('DISABLE_WP_CRON', true);, ca vizitatorii să nu mai declanșeze sarcinile. Ghidul despre dezactivarea funcțiilor WordPress inutile tratează și acest caz.

Copie de siguranță a bazei de date, zilnic

15 3 * * * /usr/bin/mysqldump --single-transaction -u utilizator -p'parola' baza | /usr/bin/gzip > /home/utilizator/backup/baza-$(date +\%F).sql.gz 2>> /home/utilizator/logs/backup.log

Semnul procent are înțeles special în cron și trebuie scris \%. Parola în linia de comandă apare în lista de procese; mai sigur este un fișier .my.cnf în directorul de acasă, cu permisiuni 600, care conține utilizatorul și parola. Copiile automate se pot face și din cPanel, cum arată ghidul despre backupul automat în cPanel, dar un cron propriu vă dă control asupra orei și a locului.

Curățarea fișierelor vechi

0 5 * * 0 /usr/bin/find /home/utilizator/backup -name '*.sql.gz' -mtime +30 -delete

Duminica la 5:00, șterge copiile mai vechi de 30 de zile. Fără o astfel de linie, directorul de copii umple discul în câteva luni și oprește site-ul.

Sarcini care nu trebuie să ruleze de două ori odată

Un import care durează 20 de minute, programat la fiecare 15, ajunge să ruleze suprapus cu el însuși. Rezultatul: date duplicate sau blocaje în baza de date. Protecția este un lacăt:

*/15 * * * * /usr/bin/flock -n /home/utilizator/tmp/import.lock /usr/local/bin/php /home/utilizator/public_html/import.php >> /home/utilizator/logs/import.log 2>&1

flock -n pornește comanda doar dacă lacătul este liber; altfel renunță fără eroare. Când rularea precedentă se termină, lacătul se eliberează singur.

Notificările pe e-mail

În partea de sus a paginii Cron Jobs este câmpul pentru adresa la care cPanel trimite ieșirea fiecărei rulări. Util în prima săptămână, când testați; după aceea devine zgomot, mai ales pentru cronurile la cinci minute.

Recomandarea: adresă completată, dar fiecare comandă cu ieșirea redirecționată în jurnal, ca e-mailul să vină doar când ceva a picat înainte să ajungă la redirecționare. Adresa trebuie să existe și să fie citită; ghidul despre configurarea unui cont de e-mail în cPanel acoperă crearea ei.

Depanarea unui cron care nu rulează

1. Rulați comanda manual din terminalul cPanel, exact cum este scrisă în cron, cu căile absolute. Dacă pică și aici, problema este comanda, nu cronul.
2. Verificați jurnalul în care redirecționați ieșirea. Un fișier gol după ora programată înseamnă că nici nu a pornit; un fișier cu erori spune ce a picat.
3. Verificați ora serverului. Un cron pus la 3:00 pe un server cu fus UTC rulează la 6:00 ora României.
4. Verificați permisiunile scriptului și ale directorului de jurnal. Cronul rulează cu utilizatorul contului, care trebuie să poată citi scriptul și scrie în jurnal.
5. Verificați limitele de resurse. Pe găzduire partajată, un script care depășește memoria sau timpul alocat este oprit fără mesaj clar; consumul se vede în cPanel, cum arată ghidul despre diagnosticarea problemelor de hosting cu Metrics.
6. Verificați că nu a fost dezactivat de furnizor. Unele găzduiri limitează cronurile la un interval minim, de exemplu 15 minute.

Un test care elimină îndoielile

* * * * * /bin/date >> /home/utilizator/logs/test-cron.log

Dacă în fișier apare câte o linie pe minut, cronul funcționează și ora serverului se citește direct de acolo. Ștergeți rândul după test.

Reguli de igienă

• Un jurnal pentru fiecare cron, în afara directorului public, ca să nu fie accesibil din browser.
• Fără cronuri la fiecare minut pentru sarcini care nu au nevoie; consumă procesor și pot fi limitate de furnizor.
• Fără parole în linia de comandă; folosiți fișiere de configurare cu permisiuni restrictive.
• Un comentariu în jurnalul dvs. de administrare pentru fiecare cron: ce face, cine l-a pus și când.
• Verificare trimestrială a listei; cronurile pentru pluginuri sau scripturi șterse rulează la nesfârșit și produc erori. Cele de bază sunt descrise în ghidul despre programarea sarcinilor cron în cPanel.

Cronuri pentru aplicații Laravel și alte cadre

Aplicațiile moderne nu cer un cron pentru fiecare sarcină, ci unul singur, care le pornește planificatorul intern. Laravel, de exemplu, are nevoie de un singur rând, la fiecare minut, iar restul programării se face din codul aplicației:

* * * * * cd /home/utilizator/app && /usr/local/bin/php artisan schedule:run >> /home/utilizator/logs/schedule.log 2>&1

Aici cd înainte de comandă contează: aplicația își găsește fișierele relativ la directorul ei. Pe găzduirea partajată, verificați că furnizorul permite cronuri la fiecare minut; dacă nu, planificatorul rulează la intervalul minim permis, iar sarcinile programate mai des decât atât se aliniază la el.

Cozile de lucru

Pentru aplicațiile care procesează sarcini în fundal, e-mailuri, rapoarte, importuri, cronul pornește un lucrător pentru cozi, cu limită de timp, ca să nu rămână blocat:

*/5 * * * * cd /home/utilizator/app && /usr/local/bin/php artisan queue:work --stop-when-empty --max-time=280 >> /home/utilizator/logs/queue.log 2>&1

Limita de 280 de secunde este sub intervalul de 5 minute, deci un lucrător se termină înainte să pornească următorul, fără suprapuneri și fără lacăt.

De reținut

Cronurile avansate sunt aceleași cinci câmpuri, scrise cu liste, intervale și pași, plus o comandă cu căi absolute, ieșire redirecționată în jurnal și, unde e cazul, un lacăt împotriva rulărilor suprapuse. Testați comanda manual, citiți jurnalul și verificați fusul orar înainte de a căuta alte cauze. Sintaxa acceptată de interfață și opțiunile ei sunt în documentația cPanel pentru Cron Jobs, iar restul panoului în documentația generală cPanel.

Dacă site-ul dvs. publică articolele cu întârziere sau are sarcini automate care nu mai rulează, verificarea face parte din auditul SEO gratuit de la GOAI, iar configurarea corectă a serverului intră în serviciile de SEO tehnic.