Nadaj małemu zadaniu harmonogramowemu jasną granicę.

Zdefiniuj jedną skończoną porcję pracy

Wyobraź sobie osobiste narzędzie, które odbudowuje małe dzienne podsumowanie z istniejących rekordów. Zadanie odczytuje ograniczony zestaw danych, przygotowuje jedno zastępcze podsumowanie i kończy działanie. Nie jest serwerem WWW i nie powinno działać między zaplanowanymi uruchomieniami. Przed dodaniem timera zapisz dane wejściowe, miejsce docelowe, oczekiwany czas trwania i to, co liczy się jako sukces.

Przykład zakłada hosta Linux z systemd i util-linux flock, dostęp administratora oraz istniejące konto i grupę bez uprawnień o nazwie fieldjob. Jego sprawdzony skrypt zadania znajduje się w /opt/field-jobs/build-summary i działa na pierwszym planie. Administrator jest właścicielem tego skryptu; konto zadania może go odczytać i wykonać, ale nie może przepisać jego kodu. Sprawdź ścieżki plików wykonywalnych w swojej dystrybucji. To są szablony, a nie zainstalowana usługa planowania OffVPS.

Skrypt musi zgłaszać niepowodzenie z niezerowym kodem wyjścia. W przypadku plików zastępczych zaprojektuj go tak, aby przygotowywał i sprawdzał tymczasowy wynik przed jego publikacją. W przypadku pracy z bazą danych użyj mechanizmu transakcji lub deduplikacji bazy danych. Sama blokada nie może sprawić, że częściowo ukończone zadanie będzie bezpieczne do powtórzenia.

Wybierz strefę czasową i politykę pominiętych uruchomień

Nasze podsumowanie jest przydatne raz dziennie o 02:15 UTC. Użyj jawnej strefy, aby lokalna strefa czasowa maszyny nie była niewidoczną zależnością. UTC unika sezonowych zmian zegara w tym przykładzie; zadanie biznesowe powiązane z lokalnym czasem cywilnym wymaga nazwanej strefy czasowej i przeglądu jej zachowania w czasie letnim. odniesienie do czasu systemd opisuje wyrażenia kalendarzowe.

Zapisz ten szablon jako /etc/systemd/system/field-summary.timer na docelowym VPS po przejrzeniu nazw:

[Unit]
Description=Daily personal-tool summary

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

[Install]
WantedBy=timers.target

Persistent=true żąda aktywacji nadrabiania zaległości po okresie bezczynności, jeśli zdarzenie kalendarzowe zostało pominięte. Nie odtwarza oddzielnego uruchomienia dla każdego pominiętego dnia. Timer nie uruchamia również kolejnej instancji tej samej usługi, gdy ta usługa jest aktywna. Te zachowania i dokładność planowania opisuje odniesienie do timera. Zdecyduj, czy spóźnione podsumowanie jest przydatne, przed włączeniem nadrabiania zaległości.

Ustaw użytkownika usługi, katalog stanu i blokadę

Pasujący /etc/systemd/system/field-summary.service opisuje pracę:

[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 pasuje do polecenia, które się kończy; jawny limit czasu startu ogranicza ten przykład. Nie dodawaj RemainAfterExit=yes do usługi, która musi stać się nieaktywna po każdym uruchomieniu. Zobacz semantykę usług systemd. Ustaw limit czasu na podstawie obciążenia i spraw, aby przerwanie było bezpieczne, zamiast zakładać, że pięć minut pasuje do każdego zadania.

Dla tej usługi systemowej StateDirectory tworzy nazwany katalog w /var/lib z własnością usługi. Katalog roboczy, użytkownik, uprawnienia i miejsca docelowe wyników są jawne; skrypt powinien używać ścieżek bezwzględnych dla własnych narzędzi i danych. Zasady środowiska i katalogów opisano w odniesieniu do wykonywania systemd. Nie umieszczaj tajnych wartości w argumentach wiersza poleceń ani nie loguj ich.

Nieblokujący flock wrapper kończy działanie z kodem 75, gdy inne współpracujące wywołanie trzyma tę blokadę. Celowo pozostawiamy to jako widoczne niepowodzenie wymagające przeglądu, zamiast traktować pominięte podsumowanie jako ukończoną pracę. Wszystkie ręczne wywołania muszą używać tego samego wrappera i ścieżki blokady. Nie usuwaj pliku blokady, aby zwolnić działające zadanie: nowy plik może utworzyć oddzielną blokadę. To wzorzec lokalnego systemu plików, a nie rozproszona blokada między instancjami VPS. Zobacz podręcznik upstream flock.

Sprawdź pliki, a następnie wypróbuj jedno kontrolowane uruchomienie

Użyj jednorazowego zestawu danych z wyłączoną pocztą wychodzącą, płatnościami i innymi efektami ubocznymi podczas pierwszego uruchomienia. Przed aktywacją sprawdź sparsowany harmonogram i pliki jednostek na tym hoście testowym:

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

Te sprawdzenia mogą wychwycić błędy jednostek i harmonogramu; nie mogą ustalić, że skrypt tworzy poprawne podsumowanie. odniesienie systemd-analyze wyjaśnia ich zakres. Po poprawieniu błędów załaduj sprawdzone pliki i jawnie uruchom zadanie testowe:

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

Oczekuj skończonego pomyślnego wywołania i zweryfikowanego artefaktu wyjściowego; pomyślny oneshot może później pokazywać stan nieaktywny. Sprawdź sam wynik, w tym zachowanie przy pustym wejściu. Wykonaj przebieg wyłącznie testowy celowo wolno, wywołaj to samo zablokowane polecenie dwukrotnie na zbiorze testowym i zweryfikuj, że drugie wywołanie zgłasza kontencję blokady bez zapisywania konkurencyjnego wyniku.

Włącz harmonogram dopiero po sprawdzeniu jego wyników

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

Sprawdź następny zaplanowany czas, a następnie przejrzyj pierwszy zaplanowany wynik. Zachowaj czas rozpoczęcia, czas zakończenia, liczbę przetworzonych elementów i wynik w logach skryptu. Brak rekordu sukcesu jest powodem do sprawdzenia, a nie dowodem, że zadanie zostało wykonane. Zapoznaj się z poleceniami timera i aktywacji systemctl.

Aby wstrzymać przyszłe uruchomienia, użyj sudo systemctl disable --now field-summary.timer. To nie kończy już działającej usługi. Jeśli potrzebne jest przerwanie, najpierw ustal, czy jej bieżący zapis można bezpiecznie zatrzymać. W miarę wzrostu pracy przejrzyj czas trwania, ponowienia i limity zewnętrznych API; wiele maszyn wymaga wspólnej koordynacji. Kontynuuj ze scenariuszem narzędzi osobistych oraz ćwiczeniem przywracania dla danych, którymi utrzymuje ta automatyzacja.