`at` kontra `cron`: kiedy używać którego narzędzia do zadań jednorazowych w Linuxie?

Planowanie zadań w systemie Linux to nie tylko kwestia wygody, ale często konieczność. Gdy mamy do czynienia z jednorazowymi akcjami — np. wykonaniem kopii zapasowej o konkretnej godzinie lub wysłaniem powiadomienia po zakończeniu długiego procesu — naturalnym wyborem wydają się narzędzia `at` i `cron`. Ale które z nich sprawdzi się lepiej? Gdzie leży granica między prostotą a elastycznością, a kiedy jedno z nich zawodzi?

Podstawowe różnice między `at` a `cron` — co warto wiedzieć przed wyborem

Zarówno at, jak i cron służą do planowania zadań, ale ich podejście do tego tematu diametralnie się różni. at został stworzony z myślą o zdarzeniach jednorazowych, które mają się uruchomić w ściśle określonym momencie w przyszłości. Jego składnia jest intuicyjna i przejrzysta, co czyni go idealnym narzędziem do szybkiego zaplanowania akcji, która nie powinna się powtarzać. Z kolei cron

to potężniejsze narzędzie, zoptymalizowane pod kątem zadań cyklicznych — takich, które mają się wykonywać co godzinę, co dzień, co tydzień lub w dowolnym, zdefiniowanym przez użytkownika interwale czasowym.

Poniższa tabela przedstawia kluczowe różnice między tymi narzędziami:

Kryterium	at	cron
Typ zadań	Jednorazowe (np. "uruchom skrypt jutro o 15:00")	Powtarzalne (np. "uruchamiaj skrypt co 2 godziny")
Składnia	Prosta: echo "komenda" | at 14:30 2024-05-20	Złożona: wymaga edycji crontab (np. 30 14 20 5 * /ścieżka/skrypt)
Elastyczność daty	Bardzo wysoka: obsługuje złożone schematy (np. "teraz + 30 minut", "jutro o północy")	Ograniczona: tylko interwały czasowe (np. co minutę, co godzinę)
Priorytety	Brak priorytetów — kolejność zależy od czasu dodania	Możliwość ustawienia priorytetów przez użytkownika (np. za pomocą nice)
Logowanie	Standardowo zapisuje polecenia i wynik do /var/log/atd (zależnie od dystrybucji)	Logi w /var/log/syslog lub /var/log/cron (zależnie od systemu)

Kiedy `at` sprawdza się lepiej niż `cron` — praktyczne przykłady

Wybór między at a cron zależy przede wszystkim od charakteru planowanego zadania. Poniżej znajdziesz konkretne scenariusze, w których at jest nie tylko wygodnym, ale i bezpiecznym wyborem:

• Wykonanie jednorazowej akcji w określonym czasie — np. wysłanie e-maila za 10 minut o 15:00:

  echo "echo 'Temat: Raport dzienny' | mail -s 'Raport' admin@example.com" | at 15:00

  W tym przypadku at pozwala na precyzyjne określenie czasu wykonania bez konieczności tworzenia wpisu w crontab.

• Automatyzacja zadań zależnych od zewnętrznych zdarzeń — np. uruchomienie konwersji pliku po zakończeniu jego pobierania:

  wget https://example.com/duzy_plik.iso && echo "/ścieżka/do/konwersji.sh" | at now + 5 minutes

  Dzięki at możesz zaplanować wykonanie akcji zaraz po zakończeniu poprzedniego procesu, nawet jeśli nie wiesz dokładnie, kiedy to nastąpi.

• Prototypowanie i testowanie skryptów — np. szybkie sprawdzenie działania skryptu o konkretnej godzinie:

  echo "ls -la /tmp > /var/log/test.log" | at now + 2 minutes

  Jest to znacznie szybsze niż edycja crontab, szczególnie w środowiskach developerskich.

• Środowiska o ograniczonych zasobach — np. kontenery Docker z minimalnym obrazem (np. Alpine Linux), gdzie cron nie jest dostępny lub jest zbyt kosztowny pod względem zasobów:

  echo "backup.sh" | at 02:00 tomorrow

Przykład porównawczy:

Załóżmy, że chcesz zaplanować wykonanie kopii zapasowej o 2:00 w nocy. Z użyciem at wygląda to tak:

echo "/ścieżka/do/backup.sh" | at 02:00 2024-05-21

Z kolei z cron musiałbyś zdefiniować wpis w crontab:

0 2 * * * /ścieżka/do/backup.sh

Pierwsze rozwiązanie jest czytelniejsze i mniej narażone na błędy składniowe, zwłaszcza dla użytkowników, którzy rzadko korzystają z cron.

Techniczne ograniczenia `at` — co może pójść nie tak?

Mimo swoich zalet, at nie jest narzędziem idealnym. Jego główne ograniczenia wynikają z prostoty i specyficznego przeznaczenia. Oto najczęstsze problemy, z którymi mogą spotkać się użytkownicy:

1. Brak obsługi środowiska użytkownika

at uruchamia zadania w minimalnym środowisku, często ignorując zmienne zdefiniowane w .bashrc lub .profile. Może to prowadzić do błędów, jeśli skrypt zależy od konkretnych zmiennych środowiskowych (np. $PATH).

Rozwiązanie: Zdefiniuj środowisko w skrypcie lub użyj pełnych ścieżek do poleceń:

echo "#!/bin/bash
export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
/ścieżka/do/backup.sh" > /tmp/backup_env.sh
echo "/tmp/backup_env.sh" | at 02:00

2. Problemy z kolejką zadań

Jeśli system jest przeciążony, zadania at mogą być opóźnione lub pominięte. Dzieje się tak, ponieważ demon atd nie ma mechanizmu priorytetyzacji — działa na zasadzie kolejki FIFO (First-In-First-Out).

Rozwiązanie: Monitoruj kolejkę zadań i usuwaj stare lub niepotrzebne wpisy:

atq  # Lista zadań w kolejce
atrm 123  # Usunięcie zadania o ID 123

3. Uprawnienia — kto może korzystać z `at`?

Domyślnie dostęp do at jest ograniczony przez pliki /etc/at.allow i /etc/at.deny. Jeśli użytkownik nie znajduje się w żadnym z nich, system zwróci błąd:

You do not have permission to use at.

Rozwiązanie: Dodaj użytkownika do /etc/at.allow lub usuń go z /etc/at.deny:

echo "użytkownik" | sudo tee -a /etc/at.allow

4. Błędy demona `atd`

Czasem demon atd nie działa poprawnie, co skutkuje tym, że zadania nie są wykonywane. Najczęstsze przyczyny to:

• Demona nie uruchomiono: sudo systemctl enable --now atd
• Problem z plikiem blokady: usuń /var/run/atd.pid i zrestartuj demona
• Brak wolnego miejsca na dysku (zadania są zapisywane w /var/spool/at)

Diagnostyka: Sprawdź status demona:

sudo systemctl status atd
journalctl -u atd --since "1 hour ago"

5. Obsługa stref czasowych

at nie zawsze uwzględnia strefę czasową użytkownika. Może to prowadzić do nieoczekiwanych wyników, jeśli użytkownik działa w innej strefie niż systemowa.

Rozwiązanie: Użyj zmiennej TZ w skrypcie lub jawnie określaj czas w UTC:

echo "TZ=UTC /ścieżka/do/skrypt.sh" | at 02:00

Instalacja `at` w popularnych dystrybucjach — jak to zrobić krok po kroku?

Choć at jest szeroko dostępny, nie zawsze jest domyślnie zainstalowany. Poniżej znajdziesz instrukcje dla najpopularniejszych dystrybucji Linux:

Dystrybucja	Domyślnie zainstalowany?	Pakiet do zainstalowania	Dodatkowe kroki
Debian / Ubuntu	Nie	at	Uruchomienie demona: sudo systemctl enable --now atd
RHEL / centos / Fedora	Tak (od RHEL 7+)	—	Sprawdź, czy demon działa: sudo systemctl status atd
Arch Linux	Nie	at	—
opensuse	Nie	at	—
Alpine Linux	Tak	—	Demona uruchamia się automatycznie z busybox

Instalacja w Debianie/Ubuntu:

sudo apt update
sudo apt install at
sudo systemctl enable --now atd

Instalacja w Arch Linux:

sudo pacman -S at

Sprawdzanie, czy demon działa:

sudo systemctl status atd

Alternatywy dla `at` — kiedy warto rozważyć inne narzędzia?

Choć at jest doskonałym rozwiązaniem dla jednorazowych zadań, w niektórych przypadkach warto rozważyć alternatywy. Poniżej porównujemy najpopularniejsze z nich:

`systemd timers` — bardziej elastyczne, ale bardziej skomplikowane

systemd timers to narzędzie wbudowane w system systemd, które oferuje większą elastyczność niż at, ale wymaga znajomości składni plików .timer i .service. Jest idealne dla użytkowników, którzy już korzystają z systemd i chcą zintegrować planowanie zadań z innymi usługami systemowymi.

Przykład: Utwórz plik /etc/systemd/system/backup.timer:

[Unit]
Description=Backup o północy

[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true

[Install]
WantedBy=timers.target

Następnie aktywuj timer:

sudo systemctl enable --now backup.timer

Zalety:

• Precyzyjne triggery (np. oparte na zdarzeniach systemowych)
• Lepsza integracja z logami systemd
• Możliwość uruchamiania zadań w odpowiedzi na zdarzenia systemowe

Wady:

• Składnia jest bardziej skomplikowana niż at
• Wymaga znajomości systemd

`fcron` — dla zadań cyklicznych o nieregularnych interwałach

fcron to alternatywa dla cron, która oferuje większą elastyczność w definiowaniu zadań cyklicznych. Jest szczególnie przydatny w środowiskach, gdzie zadania mają się wykonywać nieregularnie, np. "co 3 dni" lub "co drugi wtorek".

Przykład: Zdefiniuj zadanie w /etc/fcrontab:

3 0 * * 1,3,5 /ścieżka/do/skrypt.sh

Oznacza to, że skrypt uruchomi się w każdy poniedziałek, środę i piątek o 3:00.

Zalety:

• Wsparcie dla zadań o nieregularnych interwałach
• Lepsza obsługa środowisk z ograniczoną mocą obliczeniową

Wady:

• Mniejsza popularność niż cron
• Mniej dokumentacji i wsparcia społeczności

`anacron` — dla systemów z nieciągłą pracą

anacron to narzędzie zaprojektowane z myślą o systemach, które nie są uruchamiane cały czas (np. laptopy). Zapewnia, że zaplanowane zadania zostaną wykonane nawet wtedy, gdy system był wyłączony w zaplanowanym czasie.

Przykład: Zdefiniuj zadanie w /etc/anacrontab:

7 10 backup.daily /ścieżka/do/backup.sh

Oznacza to, że skrypt uruchomi się co 7 dni, jeśli system był wyłączony, to przy najbliższym uruchomieniu.

Zalety:

• Działa nawet przy nieregularnym działaniu systemu
• Prosta konfiguracja

Wady:

• Ograniczone do zadań dziennych/tygodniowych
• Nie nadaje się do zadań jednorazowych

Bezpieczeństwo przy używaniu `at` — jak unikać pułapek?

Mimo że at jest prostym narzędziem, jego nieprawidłowe użycie może prowadzić do problemów bezpieczeństwa. Oto najlepsze praktyki, które pomogą Ci uniknąć najczęstszych pułapek:

1. Ogranicz dostęp do `at`

Domyślnie dostęp do at jest kontrolowany przez pliki /etc/at.allow i /etc/at.deny. Najbezpieczniejszym podejściem jest utworzenie pliku /etc/at.allow i umieszczenie w nim tylko uprawnionych użytkowników.

sudo touch /etc/at.allow
echo "admin" | sudo tee -a /etc/at.allow
echo "developer" | sudo tee -a /etc/at.allow

Użytkownicy nie wymienieni w żadnym z plików nie będą mogli korzystać z at.

2. Unikaj wrażliwych poleceń w kolejce `at`

Zadania at są zapisywane w /var/spool/at w postaci czytelnej dla administratorów. Jeśli planujesz wykonanie polecenia, które zawiera hasła lub wrażliwe dane, rozważ użycie skryptów z ograniczonymi uprawnieniami lub zewnętrznych narzędzi do zarządzania tajemnicami.

3. Loguj wyniki zadań

Aby monitorować wykonanie zadań, przekieruj wyjście do pliku logów:

echo "/ścieżka/do/skrypt.sh > /var/log/at_job.log 2>&1" | at 02:00

Dzięki temu będziesz mógł łatwo zweryfikować, czy zadanie zakończyło się powodzeniem.

4. Usuwaj stare zadania

Zadania, które dawno powinny zostały wykonane, powinny być usunięte z kolejki. Możesz to zrobić ręcznie za pomocą atrm lub zautomatyzować ten proces za pomocą prostego skryptu.

# Usuń wszystkie zadania starsze niż 7 dni
atq | awk '$1 < systime() - 604800 {print $1}' | xargs -I {} atrm {}

5. Unikaj uruchamiania zadań `at` jako root

Jeśli to możliwe, uruchamiaj zadania z konta użytkownika o minimalnych uprawnieniach. Używanie root powinno być ograniczone do zadań, które wymagają uprawnień administratora.

Podsumowanie — kiedy wybrać `at`, a kiedy `cron`?

Wybór między at a cron zależy przede wszystkim od charakteru Twojego zadania:

• Użyj at, gdy:
  • Masz do czynienia z jednorazowym zadaniem w ściśle określonym czasie.
  • Potrzebujesz prostej i szybkiej metody planowania.
  • Pracujesz w środowisku, gdzie cron nie jest dostępny (np. minimalne kontenery).
  • Chcesz szybko przetestować działanie skryptu.
• Użyj cron, gdy:
  • Masz do czynienia z zadań cyklicznym (np. co godzinę, co tydzień).
  • Potrzebujesz większej elastyczności w definiowaniu interwałów.
  • Chcesz priorytetyzować zadania lub ustawiać limity czasowe.

Jeśli nadal masz wątpliwości, zacznij od at. Jego prostota i czytelność sprawiają, że jest doskonałym punktem wyjścia do automatyzacji zadań w Linuxie. Gdy Twoje potrzeby wykroczą poza jednorazowe akcje, z łatwością przejdziesz na cron lub jego alternatywy.

Źródła

• https://www.tecmint.com/at-command-linux/
• https://man7.org/linux/man-pages/man1/at.1.html
• https://man7.org/linux/man-pages/man8/cron.8.html
• https://bugzilla.redhat.com/
• https://wiki.archlinux.org/title/At
• https://packages.debian.org/search?keywords=at
• https://archlinux.org/packages/?name=at
• https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/considerations_in_adopting_rhel_9/package-list
• https://linuxize.com/post/at-vs-cron/
• https://www.digitalocean.com/community/tutorials/how-to-use-the-at-command-to-schedule-one-time-tasks-on-linux
• http://manpages.ubuntu.com/manpages/focal/man5/at.allow.5.html
• https://wiki.archlinux.org/title/At#Troubleshooting