Oferiți unei mici sarcini programate o limită clară.

Definiți o singură bucată finită de lucru

Imaginați-vă un instrument personal care reconstruiește un mic rezumat zilnic din înregistrările sale existente. Jobul citește un set limitat de date, pregătește un singur rezumat de înlocuire și iese. Nu este un server web și nu ar trebui să ruleze continuu între pornirile programate. Notați inputul, destinația, durata așteptată și ce contează ca succes înainte de a adăuga un timer.

Exemplul presupune un host Linux cu systemd și util-linux flock, acces de administrator și un cont și grup neprivilegiate existente numite fieldjob. Scriptul de job revizuit se află la /opt/field-jobs/build-summary și rulează în prim-plan. Un administrator deține acel script; contul de job îl poate citi și executa, dar nu-i poate rescrie codul. Verificați căile executabile pe distribuția dvs. Acestea sunt șabloane, nu un serviciu de programare OffVPS instalat.

Scriptul trebuie să raporteze eșecul cu un status de ieșire non-zero. Pentru fișierele de înlocuire, proiectați-l să pregătească și să verifice un rezultat temporar înainte de a-l publica. Pentru lucrul cu baza de date, utilizați mecanismul de tranzacție sau deduplicare al bazei de date. Un lacăt singur nu poate face o sarcină parțial finalizată sigură de repetat.

Alegeți un fus orar și o politică pentru rulările ratate

Rezumatul nostru este util o dată pe zi la 02:15 UTC. Utilizați o zonă explicită, astfel încât fusul orar local al mașinii să nu fie o dependență invizibilă. UTC evită schimbările sezoniere de ceas în acest exemplu; o sarcină de afaceri legată de ora civilă locală are nevoie de un fus orar numit și de o revizuire a comportamentului său la ora de vară. referința de timp systemd descrie expresiile de calendar.

Salvați acest șablon ca /etc/systemd/system/field-summary.timer pe VPS-ul dorit după revizuirea numelor:

[Unit]
Description=Daily personal-tool summary

[Timer]
OnCalendar=*-*-* 02:15:00 UTC
Persistent=true
Unit=field-summary.service

[Install]
WantedBy=timers.target

Persistent=true solicită o activare de recuperare după o perioadă inactivă dacă un eveniment de calendar a fost ratat. Nu reia o rulare separată pentru fiecare zi ratată. De asemenea, un timer nu pornește o altă instanță a aceluiași serviciu cât timp acel serviciu este activ. Aceste comportamente, și precizia programării, sunt acoperite de referința timerului. Decideți dacă un rezumat întârziat este util înainte de a activa recuperarea.

Setați utilizatorul serviciului, directorul de stare și lacătul

Corespondentul /etc/systemd/system/field-summary.service descrie lucrul:

[Unit]
Description=Build the personal-tool summary

[Service]
Type=oneshot
User=fieldjob
Group=fieldjob
WorkingDirectory=/opt/field-jobs
StateDirectory=field-summary
StateDirectoryMode=0700
UMask=0077
ExecStart=/usr/bin/flock --nonblock --conflict-exit-code 75 /var/lib/field-summary/job.lock /opt/field-jobs/build-summary
TimeoutStartSec=5min
StandardOutput=journal
StandardError=journal

Type=oneshot se potrivește unei comenzi care se finalizează; un timeout explicit de pornire delimitează acest exemplu. Nu adăugați RemainAfterExit=yes la un serviciu care trebuie să devină inactiv după fiecare rulare. Consultați semantica serviciilor systemd. Setați un timeout din volumul de lucru și faceți întreruperea sigură în loc să presupuneți că cinci minute se potrivesc fiecărui job.

Pentru acest serviciu de sistem, StateDirectory creează directorul numit sub /var/lib cu proprietate de serviciu. Directorul de lucru, utilizatorul, permisiunile și destinațiile de ieșire sunt explicite; scriptul ar trebui să folosească căi absolute pentru propriile instrumente și date. Regulile de mediu și director sunt documentate în referința de execuție systemd. Nu puneți valori secrete în argumentele liniei de comandă și nu le înregistrați.

Wrapper-ul nonblocking flock iese cu codul 75 când o altă invocare cooperantă deține acest lacăt. Lăsăm deliberat asta ca un eșec vizibil care necesită revizuire, în loc să tratăm un rezumat omis ca muncă finalizată. Toate invocările manuale trebuie să folosească același wrapper și aceeași cale de lacăt. Nu ștergeți un fișier de lacăt pentru a elibera un job care rulează: un fișier nou poate crea un lacăt separat. Acesta este un model pentru sistemul de fișiere local, nu un lacăt distribuit între instanțe VPS. Consultați manualul upstream flock.

Verificați fișierele, apoi încercați o rulare controlată

Utilizați un set de date de unică folosință cu e-mailul de ieșire, plățile și alte efecte secundare dezactivate pentru prima rulare. Înainte de activare, inspectați programul analizat și fișierele unit pe acel host de test:

systemd-analyze calendar '*-*-* 02:15:00 UTC'
systemd-analyze verify /etc/systemd/system/field-summary.service /etc/systemd/system/field-summary.timer

Aceste verificări pot prinde greșeli de unit și de programare; nu pot stabili că scriptul dvs. produce un rezumat corect. referința systemd-analyze le explică domeniul de aplicare. După corectarea erorilor, încărcați fișierele revizuite și porniți explicit jobul de test:

sudo systemctl daemon-reload &&
  sudo systemctl start field-summary.service
systemctl status field-summary.service --no-pager
sudo journalctl -u field-summary.service --since "10 minutes ago" --no-pager

Așteptați o invocare reușită finită și un artefact de ieșire verificat; o oneshot reușită poate apărea ca inactivă ulterior. Inspectați rezultatul în sine, inclusiv comportamentul la intrare goală. Faceți o rulare doar pentru test în mod deliberat lentă, invocați aceeași comandă blocată de două ori pe setul de date de test și verificați că a doua invocare raportează contenție de blocare fără a scrie un rezultat concurent.

Activați programarea doar după verificarea rezultatului său

sudo systemctl enable --now field-summary.timer
systemctl list-timers field-summary.timer --all

Verificați următoarea oră programată, apoi examinați primul rezultat programat. Păstrați ora de început, ora de sfârșit, numărul de elemente procesate și rezultatul în jurnalele scriptului. O înregistrare de succes absentă este un motiv de inspecție, nu dovada că jobul a rulat. Consultați comenzile de timer și activare ale systemctl.

Pentru a întrerupe pornirile viitoare, utilizați sudo systemctl disable --now field-summary.timer. Aceasta nu termină un serviciu deja în execuție. Dacă este necesară întreruperea, stabiliți mai întâi dacă scrierea sa curentă poate fi oprită în siguranță. Pe măsură ce volumul de lucru crește, examinați durata, reîncercările și limitele API-urilor externe; mai multe mașini necesită coordonare partajată. Continuați cu scenariul uneltelor personale și un exercițiu de restaurare pentru datele pe care le întreține această automatizare.