Czasem potrzeba uruchomić jakieś polecenie, czy jakiś skrypt automatycznie, w określonym momencie (czasie), i tu z pomocą przychodzi nam CRON – rodzaj systemowego harmonogramu zadań w systemie Linux, a tym samym w Raspberry Pi. Nie będę opisywał całej struktury i zasady działania, gdyż w Internecie można znaleźć na ten temat wiele przystępnie napisanych poradników. Ale jednak jakieś podstawy postaram się podać, tak by zostało w pamięci, że takie narzędzie istnieje, i czasem może nam się przydać (np. kopie zapasowe, czy automatyczne aktualizacje systemu).
Spis treści w artykule
CRON i CRONTAB
W uproszczeniu CRON to usługa, która korzysta z tabel z zadaniami, tzw. „crontab”:
cron – uniksowy daemon zajmujący się okresowym wywoływaniem innych programów. Posługuje się on tabelami crontab do przechowywania informacji jakie zadanie ma uruchamiać.
Źródło: Wikipedia
Warto zacząć od sprawdzenia, czy w naszym systemie usługa działa. W tym celu korzystamy z polecenia:
/etc/init.d/cron status
Jak widać – usługa działa:
[ ok] cron is running.
Zadania użytkownika
Jako użytkownik możemy zdefiniować zadania, które system wykona automatycznie „w naszym imieniu” (z uprawnieniami naszego użytkownika) korzystając z polecenia:
crontab -e
Otworzy nam się „plik tekstowy” w który możemy dodawać kolejne pozycje/polecenia.
Składnia wpisów jest następująca:
[minuty(0-59)] [godzina(0-23)] [dzień_miesiąca(0-31)] [miesiąc(1-12)] [dzień_tygodnia(0-7, 0/7-niedziela)] [polecenie]
* * * * * skrypt/polecenie
* * * * * skrypt/polecenie1; skrypt/polecenie2
Możemy stosować:
- * – zawsze (każda minuta, każda godzina, każdy dzień, każdy miesiąc, każdy dzień tygodnia)
- Zakres: x-y – czyli od „x” do „y”, np. „1-5” to każda minuta/godzina/dzień/miesiąc od 1 do 5
- Przerwa: */x – np. „*/8” to polecenie wykonane co 8 minut/godzin/dni…
- Kolejne wartości: x,y,z – np. „2,5,8” może oznaczać polecenie wykonane w 2, 5 i 8 minucie/godzinie…
- Wiele zadań w jednym wpisie: ; rozdzielamy polecenia
Kilka przykładów, by lepiej zrozumieć zasadę budowy:
- */5 * * * * [Co 5 minut]
- 0 4 * * * [O 4 rano]
- 0 5 * * 0 [O 5 rano w niedzielę (0 lub 7)]
- 15 8,10 1-15 1 * [O 8:15 i 10:15, od 1 do 15 stycznia (1)]
W pewnych przypadkach (np. błędy) system może wysyłać na powiadomienie na e-mail (zależy od konfiguracji systemu). Możemy wyłączyć taką informację dla konkretnego zadania, dodając:
>/dev/null 2>&1
na końcu linii z poleceniem, np.:
5 10 * * * skrypt_lub_polecenie >/dev/null 2>&1
Skrypt lub polecenie wykona się o 10:05 (codziennie), a ew. raport „poleci w kosmos”.
Cron(tab) systemowy
Oprócz naszego, indywidualnego (użytkownika) istnieje też „systemowa” tabela zadań Cron.
sudo nano /etc/crontab
Budowa wpisów jest podobna do tabeli użytkownika, z tym że dodatkowo między „kiedy” a „komenda/polecenie” należy podać użytkownika, w „imieniu którego” wykona się konkretne polecenie:
Skrypty w katalogach cron.x
Kolejne miejsce związane z tematem to katalogi, w których znajdują się skrypty uruchamiane w określonych okresach.
Są to:
- /etc/cron.daily – codziennie
- /etc/cron.hourly – co godzinę
- /etc/cron.weekly – raz w tygodniu
- /etc/cron.monthly – raz w miesiącu
Każdy skrypt, który znajduje się w tych katalogach, zostanie uruchomiony zgodnie z jego nazwą.
@reboot
Wprawdzie jest to element zarządzania, kiedy ma się uruchomić dane polecenie czy skrypt, ale jest na tyle inne od pozostałych, że postanowiłem je wydzielić.
Za pomocą wpisu z @reboot otrzymacie możliwość uruchamiania polecenia/skryptu przy każdym uruchomieniu systemu. Np. by wyświetlić przy każdym uruchomieniu systemu komunikat „System uruchomiony” dodajemy do CRONa taką linijkę:
@reboot echo "System uruchomiony"
@reboot /ścieżka/do/skryptu
@reboot wpisujemy jako określenie, kiedy ma się uruchamiać skrypt, czyli zamiast „* * * * *”.
Można też wykonanie zadania opóźnić, np. o 20 sekund:
@reboot sleep 20 && /ścieżka/do/skryptu
Gdyby takie zadania się nie wykonywały, to warto sprawdzić, czy CRON startuje przy starcie systemu:
sudo systemctl status cron.service
I ew. aktywować:
sudo systemctl enable cron.service
Zarządzanie CRONem
Jeszcze kilka poleceń, które mogą się przydać – restart usługi:
sudo /etc/init.d/cron restart
Ręczny start usługi:
sudo /etc/init.d/cron start
Ręczne zatrzymanie usługi:
sudo /etc/init.d/cron stop
/var/log/cron.log
Warto aktywować logi zadań CRON’a, zwłaszcza gdy macie więcej wpisów i nie macie pewności, że wszystko idzie „zgodnie z planem harmonogramem” ;-)
Zaczynamy od edycji pliku:
sudo nano /etc/rsyslog.conf
I szukamy linijki (~ nr 63):
#cron.* /var/log/cron.log
i zmieniamy na:
cron.* /var/log/cron.log
Teraz tylko restart „logera”:
sudo /etc/init.d/rsyslog restart
Log z zadań CRONa będzie teraz zapisywany do pliku:
/var/log/cron.log
MAILTO
By się ustrzec – zwłaszcza jak mamy więcej, często uruchamianych zadań – niepotrzebnych „śmieci” w logach, np.:
MAIL (mailed 1 byte of output; but got status 0x0044, #012)
warto jeszcze dodać tablicach CRONa:
crontab -e
następujący wpis:
MAILTO=""
I tu z doświadczenia powiem, że czasem może być potrzeba dodania tego wpisu dla wszystkich użytkowników, nawet tych, co nie mają żadnych zadań.
Pewnie nie zaszkodzi dodać wpisu również do CRONa systemowego:
sudo nano /etc/crontab
Pamiętajcie, o restarcie usługi na koniec:
sudo /etc/init.d/cron restart
- Wakacje składkowe ZUS a zawieszenie działalności gospodarczej, czyli uważaj, bo być może nie będziesz mógł skorzystać (w 2024) - 1970-01-01
- Przykładowy kalkulator wyceny usługi druku 3D, czyli nie tylko materiał się liczy - 1970-01-01
- Home Assistant 2024.10, czyli nowa karta „nagłówek” i niedziałający TTS w ramach usługi Google Cloud - 1970-01-01
Witam.
Mam spore problemy z cron na aspbery Pi (Raspbian).
Status niby ok:
root@raspberrypi:/home/pi# /etc/init.d/cron status
[ ok ] cron is running.
root@raspberrypi:/home/pi#
Tabela ustawiona przez crontab -e
[code]
# Edit this file to introduce tasks to be run by cron.
#
# Each task to run has to be defined through a single line
# indicating with different fields when the task will be run
# and what command to run for the task
#
# To define the time you can provide concrete values for
# minute (m), hour (h), day of month (dom), month (mon),
# and day of week (dow) or use '*’ in these fields (for 'any’).#
# Notice that tasks will be started based on the cron’s system
# daemon’s notion of time and timezones.
#
# Output of the crontab jobs (including errors) is sent through
# email to the user the crontab file belongs to (unless redirected).
#
# For example, you can run a backup of all your user accounts
# at 5 a.m every week with:
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
#
# For more information see the manual pages of crontab(5) and cron(8)
#
# m h dom mon dow command
*/60 * * * * killall motion ; sleep 5 ; motion ; echo "`date +%Y.%m.%d-%T` – motion restarted…" >> /var/log/crontab/`date +%Y.%m.%d`.log
* 4 * * * amixer cset numid=1 — 75% ; echo "`date +%Y.%m.%d-%T` – system volume set to 75%…" >> /var/log/crontab/`date +%Y.%m.%d`.log
* 9 * * * amixer cset numid=1 — 100% ; echo "`date +%Y.%m.%d-%T` – system volume set to 100%…" >> /var/log/crontab/`date +%Y.%m.%d`.log
* * * * * /usr/bin/espeak -v pl "`date +%T`" ; echo "`date +%Y.%m.%d-%T` – Powiedziano godzine…" >> /var/log/crontab/`date +%Y.%m.%d`.log
[/code]
A niestey żadne z poleceń się nie wykonuje…
Ktoś pomoże?
http://forum.r-pi.pl/raspbian/crontab-polecenia-nie-wykonuj-t149989.html
Sprawdź log z CRONa:
W ramach testów warto na pewno każde polecenie/zestaw poleceń wykonać z osobna... Niekoniecznie nawet z poziomu CRONa, a wręcz przeciwnie...
Zacząłbym np. od:
Nie wiem czy korzystasz z Sovtol, ale jakoś tak mi się ta komenda kojarzy...
W przypadku Pi "w standardzie" chyba wygląda to jakoś tak:
Wprawdzie można sterować poziomem głośności stosując wartości w zakresie 0 - 400 i/lub -1 i -10238 (-10239 to wyciszenie/mute), to jednak zdecydowanie bardziej "po ludzku" będzie skorzystać z procentów. Wtedy też stosujesz "--" dla 0-400, lub "-- -" dla wartości "negatywnych".
Ale jeszcze przez jakieś 2 dni nie mam jak tego sprawdzić, więc to tylko teoria - bo "gdzieś kiedyś coś chyba" czytałem, że w Pi nie działa "sprzętowa" regulacja głośności ;-)
Bardziej "zaawansowane" wpisy czasem warto przenieść do skryptów - wtedy wpis w CRONie wygląda przejrzyściej... I w takiej sytuacji zdecydowanie łatwiej stwierdzić czy to nie działa coś po stronie CRONa, czy może sam skrypt wykonuje się nieprawidłowo.
Pamiętaj tylko by w przypadku większej liczby użytkowników odpowiednio zabezpieczyć dostęp (zwłaszcza możliwość edycji) skryptów wykonywanych z poziomu konta "root" - no chyba, że to "100% proof" :-)
Artykuł zwięzły i na temat, ale te pseudo patriotyczne wstawki i nawiązanie do wyborczej są żenujące i nie przystoją w branżowej tematyce.
Ależ w (tym) artykule/poradniku nie ma ani jednej wstawki „pseudo patriotycznej” czy też nawiązania do GW. Być może masz na myśli ramkę zachęcającą obecnie do komentowania (jest to dynamiczna ramka, która pojawia się na rożnych stronach, z różną treścią, zależy od potrzeb/chwili), ale nie widzę tam nic z tego co napisałeś, poza faktem, że faktycznie u nas w przeciwieństwie do GW komentarz może napisać każdy i bezpłatnie… ;-)
A co do „nie przystoją w branżowej tematyce” to dlatego, że tak kto(ś) twierdzi, czy są jakieś „branżowe prawidła”, które przegapiłem? No chyba, że „w branżuni” można – niczym w Google – tylko w lewo?
Mam problem z zadaniem cron.
Co znaczy „send-campaigns” w poniższym zadaniu:
* * * * * /usr/bin/php -q /home/mailserver/public_html/apps/console/console.php send-campaigns >/dev/null 2>&1
Czy zadanie cron będzie działać tak samo jeżeli ustawie je w panelu, np:
* * * * * /usr/bin/php -q /home/mailserver/public_html/apps/console/console.php
W powyższym „send-campaigns” to najprawdopodobniej parametr, z którym uruchamiany jest skrypt (console.php), i jest spora szansa, że zadanie uruchomione bez tego parametru będzie działać inaczej niż z. Chyba, że zadanie przypisane do tego parametru jest zadaniem domyślnym, wtedy zadziała również bez. Ale na to pytanie zapewne pomoże odpowiedzieć dokumentacja skryptu (prawdopodobnie mowa o MailWizz EMA) lub bezpośredni wgląd w kod. Ale też nie widzę racjonalnego powodu, dla którego chcesz aż tak modyfikować polecenie, zwłaszcza, jeśli masz gotowca do zastosowania. Mam tylko nadzieję, że nie zamierzasz wysyłać SPAMu… ;-)
Niestety przez konsole nie moge dodac zadania cron u mnie w hostingu… a w panelu nie mam opcji dodania zadania z parametrem..
To chyba pora zmienić hosting. Zadanie z parametrem dodajesz w panelu (cPanel czy DirectAdmin) tak samo jak każde inne, czyli po prostu wklej w miejsce na polecenie:
Oczywiście polecenie to musisz dostosować do własnego systemu/serwera (np. ścieżki).
Słaba jest ta Wasza szata graficzna jak z pogrzebu :-/ Jeżeli ktoś umarł to przepraszam
Normanie jest bardziej kolorowo (i zielono), ale taki „gest” dziś, w związku ze śmiercią Stephena Hawkinga…
Jak uruchomić program GUI np. przeglądarkę po starcie systemu
@reboot /usr/bin/chrominium-browser http://www.google.com
W ogóle nie korzystam z GUI w Linuksie, bo w okienkach to wolę w Windowsie pracować, ale jakbym chciał coś takiego zorbić w Debianie, to bym pewnie zamiast CRONem, to zainteresował się .bashrc (w katalogu domowym użytkownika) i tam:
Ew. plikiem rc.local (rc-local.service).