Generator timera systemd
Zbuduj plik .timer z harmonogramem OnCalendar, opcją Persistent i wskazaniem na jednostkę .service.
-
1Wprowadź dane
Wpisz treść, wklej tekst lub załaduj plik z dysku. -
2Kliknij przycisk
Narzędzie natychmiast przetworzy Twoje dane w przeglądarce. -
3Pobierz wynik
Skopiuj gotowy tekst lub zapisz plik na urządzeniu.
return "Wynik gotowy w 0.1s";
}
Oceń to narzędzie:
Powiązane narzędzia
Inne narzędzia, które mogą Ci się przydaćGenerator timera systemd — plik .timer z harmonogramem OnCalendar
Generator timera systemd buduje gotowy plik .timer: sekcję [Timer] z harmonogramem OnCalendar, opcjonalnym Persistent=true i RandomizedDelaySec, wskazanie na jednostkę .service o tej samej nazwie oraz sekcję [Install] z WantedBy=timers.target. Wpisz nazwę, harmonogram i opis, a skopiujesz wynik prosto do /etc/systemd/system/.
Timer to tylko harmonogram — pracę wykonuje usługa
Najważniejsze: sam plik .timer nic nie uruchamia. Timer jest wyłącznie zegarem, który we właściwej chwili aktywuje jednostkę .service. Domyślnie systemd szuka usługi o tej samej nazwie co timer — jeśli masz backup.timer, musi istnieć backup.service. Generator dopisuje to powiązanie jawnie linią Unit=nazwa.service. Bez pliku .service systemctl enable --now backup.timer włączy zegar, ale o wyznaczonej godzinie systemd nie znajdzie usługi i zapisze błąd w dzienniku. Usługę możesz przetestować ręcznie (systemctl start backup.service), zanim podepniesz zegar.
Anatomia pliku .timer
| Dyrektywa | Sekcja | Rola |
|---|---|---|
Description= | [Unit] | Czytelny opis widoczny w systemctl list-timers |
OnCalendar= | [Timer] | Harmonogram w formacie kalendarzowym (godziny, dni, miesiące) |
Persistent=true | [Timer] | Nadrabia uruchomienia pominięte, gdy serwer był wyłączony |
RandomizedDelaySec= | [Timer] | Losowe opóźnienie startu — rozkłada obciążenie wielu maszyn |
Unit= | [Timer] | Jednostka .service, którą timer ma uruchomić |
WantedBy=timers.target | [Install] | Cel, który aktywuje timer przy systemctl enable |
Składnia OnCalendar — jak zapisać harmonogram
Wartość OnCalendar przyjmuje dwie postaci. Skróty opisowe: daily, hourly, weekly (poniedziałek o północy), monthly (pierwszy dzień miesiąca). Postać kalendarzowa ma format DzieńTygodnia Rok-Miesiąc-Dzień Godzina:Minuta:Sekunda, gdzie * oznacza „każdy”. Przykłady: *-*-* 02:00:00 to codziennie o 2:00, Mon *-*-* 08:00:00 to poniedziałki o 8:00, a *-*-01 00:00:00 to pierwszy dzień miesiąca. Zapis sprawdzisz bez wdrażania poleceniem systemd-analyze calendar "Mon *-*-* 08:00:00". Poza OnCalendar istnieją wyzwalacze względne OnBootSec= i OnUnitActiveSec=; dopisujesz je ręcznie w sekcji [Timer].
Persistent i RandomizedDelaySec — dwie opcje, które robią różnicę
Persistent=true zadanie zaplanowane na czas, gdy maszyna była wyłączona, zostaje pominięte. Dla backupów i rotacji logów to zwykle błąd — włącz tę opcję, a systemd wykona zaległe zadanie zaraz po starcie.RandomizedDelaySec dodaje losowe opóźnienie w podanym zakresie (np. 5m, 1h). Ma sens, gdy wiele serwerów odpala to samo zadanie o tej samej godzinie i nie chcesz, żeby wszystkie naraz uderzyły w jeden zasób.
Jak korzystać z generatora
- Wpisz nazwę timera bez rozszerzenia (np.
backup) — powstaniebackup.timeri wskazanie nabackup.service. - Podaj opis i harmonogram
OnCalendar; w razie potrzeby ustawRandomizedDelaySeci zaznaczPersistent. - Kliknij Generuj timer i skopiuj wynik do
/etc/systemd/system/backup.timer. - Utwórz parę
backup.servicez sekcją[Service]iExecStart=— bez niej timer nie ma czego uruchomić. - Wykonaj
systemctl daemon-reload,systemctl enable --now backup.timer, a harmonogram sprawdź przezsystemctl list-timers.
Timery systemd to nowocześniejszy następca crona. Jeśli porównujesz oba podejścia, przyda się generator crontab. Zadanie w kontenerze opiszesz obrazem z generatora pliku Dockerfile, a lokalne skróty zbierzesz w generatorze Makefile. Przy porządkach w repozytorium pomoże generator pliku .dockerignore, a przy publikacji na serwerze Apache generator pliku .htaccess.
Timer systemd czy cron?
Cron jest prostszy w jednej linii, ale timer systemd wygrywa tam, gdzie liczy się niezawodność. Logi zadania trafiają do journald (journalctl -u backup.service), więc widzisz wynik i błędy bez własnego przekierowania. Timer respektuje zależności między jednostkami, limity zasobów z sekcji [Service] i nadrabia pominięte uruchomienia. Cron milczy, dopóki nie ustawisz MAILTO.
Czego to narzędzie nie robi
Generator tworzy wyłącznie plik .timer. Parę .service z ExecStart= piszesz osobno — bez niej timer jest zegarem bez alarmu. Nie obsługuje też wyzwalaczy OnBootSec/OnUnitActiveSec ani kilku pozycji OnCalendar naraz; te dopisujesz ręcznie.
Najczęściej zadawane pytania
Dlaczego timer się nie uruchamia, mimo że jest włączony?
Najczęściej brakuje pary .service albo ma inną nazwę niż timer. Timer backup.timer szuka backup.service; jeśli usługa nazywa się inaczej, wskaż ją linią Unit=. Stan sprawdzisz przez systemctl status backup.timer, a dziennik przez journalctl -u backup.service.
Co daje Persistent=true?
Jeśli maszyna była wyłączona lub uśpiona o zaplanowanej porze, zadanie z Persistent=true wykona się zaraz po starcie. Bez tej opcji pominięte uruchomienie przepada do następnego terminu. Dla backupów i konserwacji zwykle chcesz ją włączyć.
Jak sprawdzić, kiedy timer wystartuje następnym razem?
Polecenie systemctl list-timers pokazuje aktywne timery z kolumnami NEXT i LAST. Samą składnię OnCalendar zweryfikujesz bez włączania timera przez systemd-analyze calendar "*-*-* 02:00:00".
Gdzie zapisać plik .timer i jak go włączyć?
Jednostki tworzone przez administratora idą do /etc/systemd/system/. Po dodaniu pliku wykonaj systemctl daemon-reload, żeby systemd go wczytał, a potem systemctl enable --now nazwa.timer, aby włączyć go teraz i przy każdym starcie systemu.