Uruchamianie crona co 30 sekund

Ok, więc mam crona, który muszę uruchamiać co 30 sekund.

Oto co mam:

*/30 * * * * /bin/bash -l -c 'cd /srv/last_song/releases/20120308133159 && script/rails runner -e production '\''Song.insert_latest'\'''

Działa, ale czy działa to co 30 minut lub 30 sekund?

Czytałem również, że cron może nie być najlepszym narzędziem do użycia, jeśli uruchamiam go tak często. Czy istnieje inne lepsze narzędzie, którego mogę użyć lub zainstalować na Ubuntu 11.04, które byłoby lepszą opcją? Czy istnieje sposób na naprawienie powyższego crona?

Masz */30w specyfikatorze minut - to znaczy co minutę, ale z krokiem 30 (innymi słowy co pół godziny). Ponieważ cronnie sprowadza się to do rozdzielczości poniżej minuty, musisz znaleźć inną drogę.

Jedną z możliwości, choć jest to trochę kludge ^(a) , jest posiadanie dwóch zadań, jedno przesunięte o 30 sekund:

# Need these to run on 30-sec boundaries, keep commands in sync.
* * * * *              /path/to/executable param1 param2
* * * * * ( sleep 30 ; /path/to/executable param1 param2 )

Zobaczysz, że dodałem komentarze i sformatowałem je, aby zapewnić łatwą synchronizację.

Oba cronzadania faktycznie uruchomić każdą minutę, ale ten ostatni z nich będzie czekać pół minuty przed wykonaniem „mięso” zadania, /path/to/executable.

W przypadku innych ( cronnieopartych na opcjach) opcji zobacz inne odpowiedzi tutaj, szczególnie te, które wspominają fcroni systemd. Prawdopodobnie są one preferowane przy założeniu, że Twój system ma możliwość ich używania (na przykład instalowania fcronlub posiadania dystrybucji systemd).

Jeśli nie chcesz używać rozwiązania kludgy, możesz użyć rozwiązania opartego na pętli z niewielką modyfikacją. Nadal będziesz musiał zarządzać utrzymywaniem procesu w jakiejś formie, ale po posortowaniu następujący skrypt powinien działać:

#!/bin/env bash

# Debug code to start on minute boundary and to
# gradually increase maximum payload duration to
# see what happens when the payload exceeds 30 seconds.

((maxtime = 20))
while [[ "$(date +%S)" != "00" ]]; do true; done

while true; do
    # Start a background timer BEFORE the payload runs.

    sleep 30 &

    # Execute the payload, some random duration up to the limit.
    # Extra blank line if excess payload.

    ((delay = RANDOM % maxtime + 1))
    ((maxtime += 1))
    echo "$(date) Sleeping for ${delay} seconds (max ${maxtime})."
    [[ ${delay} -gt 30 ]] && echo
    sleep ${delay}

    # Wait for timer to finish before next cycle.

    wait
done

Sztuką jest użycie przycisku sleep 30ale, aby uruchomić go w tle przed uruchomieniem ładunku. Następnie po zakończeniu ładunku wystarczy poczekać na zakończenie tła sleep.

Jeśli ładunek zajmuje nsekundy (gdzie n <= 30), wówczas oczekiwanie po ładunku wynosi 30 - nsekundy. Jeśli zajmie to więcej niż 30 sekund, następny cykl zostanie opóźniony, aż ładunek się skończy, ale już nie.

Zobaczysz, że mam tam kod debugowania, aby rozpocząć od jednominutowej granicy, aby początkowo łatwiej było śledzić dane wyjściowe. Stopniowo zwiększam również maksymalny czas ładunku, aby w końcu zobaczysz, że ładunek przekracza 30 sekundowy cykl (generowany jest dodatkowy pusty wiersz, więc efekt jest oczywisty).

Następuje przebieg próbny (gdzie cykle zwykle rozpoczynają się 30 sekund po poprzednim cyklu):

Tue May 26 20:56:00 AWST 2020 Sleeping for 9 seconds (max 21).
Tue May 26 20:56:30 AWST 2020 Sleeping for 19 seconds (max 22).
Tue May 26 20:57:00 AWST 2020 Sleeping for 9 seconds (max 23).
Tue May 26 20:57:30 AWST 2020 Sleeping for 7 seconds (max 24).
Tue May 26 20:58:00 AWST 2020 Sleeping for 2 seconds (max 25).
Tue May 26 20:58:30 AWST 2020 Sleeping for 8 seconds (max 26).
Tue May 26 20:59:00 AWST 2020 Sleeping for 20 seconds (max 27).
Tue May 26 20:59:30 AWST 2020 Sleeping for 25 seconds (max 28).
Tue May 26 21:00:00 AWST 2020 Sleeping for 5 seconds (max 29).
Tue May 26 21:00:30 AWST 2020 Sleeping for 6 seconds (max 30).
Tue May 26 21:01:00 AWST 2020 Sleeping for 27 seconds (max 31).
Tue May 26 21:01:30 AWST 2020 Sleeping for 25 seconds (max 32).
Tue May 26 21:02:00 AWST 2020 Sleeping for 15 seconds (max 33).
Tue May 26 21:02:30 AWST 2020 Sleeping for 10 seconds (max 34).
Tue May 26 21:03:00 AWST 2020 Sleeping for 5 seconds (max 35).
Tue May 26 21:03:30 AWST 2020 Sleeping for 35 seconds (max 36).

Tue May 26 21:04:05 AWST 2020 Sleeping for 2 seconds (max 37).
Tue May 26 21:04:35 AWST 2020 Sleeping for 20 seconds (max 38).
Tue May 26 21:05:05 AWST 2020 Sleeping for 22 seconds (max 39).
Tue May 26 21:05:35 AWST 2020 Sleeping for 18 seconds (max 40).
Tue May 26 21:06:05 AWST 2020 Sleeping for 33 seconds (max 41).

Tue May 26 21:06:38 AWST 2020 Sleeping for 31 seconds (max 42).

Tue May 26 21:07:09 AWST 2020 Sleeping for 6 seconds (max 43).

Jeśli chcesz uniknąć niechlujnego rozwiązania, prawdopodobnie jest to lepsze. Nadal będziesz potrzebować cronzadania (lub odpowiednika), aby okresowo wykrywać, czy ten skrypt jest uruchomiony, a jeśli nie, uruchom go. Ale sam skrypt obsługuje czas.

^(a) Niektórzy z moich kolegów z pracy powiedzieliby, że kludges to moja specjalność :-)

Nie możesz Cron ma ziarnistość 60 sekund.

* * * * * cd /srv/last_song/releases/20120308133159 && script/rails runner -e production '\''Song.insert_latest'\''
* * * * * sleep 30 && cd /srv/last_song/releases/20120308133159 && script/rails runner -e production '\''Song.insert_latest'\''

Szczegółowość Crona trwa kilka minut i nie została zaprojektowana tak, aby budzić się co xsekundę, aby coś uruchomić. Uruchom powtarzające się zadanie w pętli i powinno zrobić to, czego potrzebujesz:

#!/bin/env bash
while [ true ]; do
 sleep 30
 # do what you need to here
done

Jeśli korzystasz z najnowszego systemu operacyjnego Linux z SystemD, możesz użyć jednostki SystemD Timer do uruchomienia skryptu na dowolnym poziomie szczegółowości (teoretycznie do nanosekund) i - jeśli chcesz - o wiele bardziej elastycznymi regułami uruchamiania niż kiedykolwiek dozwolone . Nie sleepsą wymagane żadne kostki

Konfiguracja zajmuje więcej niż pojedynczą linię w pliku cron, ale jeśli potrzebujesz czegoś lepszego niż „Co minutę”, to jest warte wysiłku.

Model timera SystemD jest w zasadzie taki: timery to jednostki, które uruchamiają jednostki serwisowe po upływie timera .

Tak więc dla każdego skryptu / polecenia, które chcesz zaplanować, musisz mieć jednostkę serwisową, a następnie dodatkową jednostkę czasową. Pojedyncza jednostka czasowa może zawierać wiele harmonogramów, więc zwykle nie potrzebujesz więcej niż jednego timera i jednej usługi.

Oto prosty przykład, który rejestruje „Hello World” co 10 sekund:

/etc/systemd/system/helloworld.service:

[Unit]
Description=Say Hello
[Service]
ExecStart=/usr/bin/logger -i Hello World

/etc/systemd/system/helloworld.timer:

[Unit]
Description=Say Hello every 10 seconds
[Timer]
OnBootSec=10
OnUnitActiveSec=10
AccuracySec=1ms
[Install]
WantedBy=timers.target

Po skonfigurowaniu tych urządzeń (w /etc/systemd/system, jak opisano powyżej, dla ustawień ogólnosystemowych lub ~/.config/systemd/userdla konfiguracji specyficznych dla użytkownika), musisz włączyć licznik czasu (nie usługa), uruchamiając się systemctl enable --now helloworld.timer( --nowflaga również uruchamia licznik czasu natychmiast, inaczej uruchomi się dopiero po następnym uruchomieniu lub logowaniu użytkownika).

Zastosowane [Timer]tutaj pola sekcji są następujące:

• OnBootSec - uruchom usługę tyle sekund po każdym uruchomieniu.
• OnUnitActiveSec- uruchomić usługę tyle sekund po ostatnim uruchomieniu usługi. To powoduje, że licznik czasu powtarza się i zachowuje się jak zadanie cron.
• AccuracySec- ustawia dokładność timera. Liczniki czasu są tak dokładne, jak to pole ustawione, a wartość domyślna to 1 minuta (emuluje cron). Głównym powodem, dla którego nie wymaga się najlepszej dokładności, jest poprawa zużycia energii - jeśli SystemD może zaplanować kolejny przebieg w taki sposób, aby zbiegał się z innymi zdarzeniami, musi rzadziej budzić procesor. Powyższy 1msprzykład nie jest idealny - zwykle ustawiam dokładność na 1(1 sekundę) w moich zaplanowanych podminutowych zadaniach, ale oznaczałoby to, że jeśli spojrzysz na dziennik z komunikatami „Hello World”, zobaczysz, że często jest późno o 1 sekundę. Jeśli nie masz nic przeciwko, sugeruję ustawienie dokładności na 1 sekundę lub dłużej.

Jak zapewne zauważyłeś, ten zegar nie naśladuje Crona aż tak dobrze - w tym sensie, że polecenie nie rozpoczyna się na początku każdego okresu zegara ściennego (tzn. Nie zaczyna się od 10 sekundy zegara, następnie 20. i tak dalej). Zamiast tego dzieje się tak, gdy zegar mija. Jeśli system uruchomił się o 12:05:37, to następnym razem polecenie zostanie uruchomione o 12:05:47, a następnie o 12:05:57 itd. Jeśli jesteś zainteresowany rzeczywistą dokładnością zegara ściennego, możesz aby wymienić OnBootSeci OnUnitActiveSecpola, a zamiast ustawić OnCalendarregułę z harmonogramem, który chcesz (który o ile mi zrozumieć nie może być szybszy niż 1 sekundę, w formacie kalendarza). Powyższy przykład można również zapisać jako:

OnCalendar=*-*-* *:*:00,10,20,30,40,50

Ostatnia uwaga: jak się zapewne domyślacie, helloworld.timerjednostka uruchamia helloworld.servicejednostkę, ponieważ mają one tę samą nazwę (minus sufiks typu jednostki). Jest to ustawienie domyślne, ale można to zmienić, ustawiając Unitpole dla [Timer]sekcji.

Więcej krwawych szczegółów można znaleźć na:

• Wyloguj stronę Wiki Linux-a dotyczącą timerów SystemD, która daje bardzo dobry przegląd tematu wraz z przykładami.
• man systemd.timer
• man systemd.time
• man systemd.service
• man system.exec

Nie potrzebujesz dwóch wpisów cron, możesz połączyć je w jeden z:

* * * * * /bin/bash -l -c "/path/to/executable; sleep 30 ; /path/to/executable"

więc w twoim przypadku:

* * * * * /bin/bash -l -c "cd /srv/last_song/releases/20120308133159 && script/rails runner -e production '\''Song.insert_latest'\'' ; sleep 30 ; cd /srv/last_song/releases/20120308133159 && script/rails runner -e production '\''Song.insert_latest'\''"

Możesz sprawdzić moją odpowiedź na to podobne pytanie

Zasadniczo zawarłem tam skrypt bash o nazwie „runEvery.sh”, który możesz uruchamiać z cronem co 1 minutę i przekazywać jako argumenty prawdziwe polecenie, które chcesz uruchomić, i częstotliwość w sekundach, w których chcesz go uruchomić.

coś takiego

* * * * * ~/bin/runEvery.sh 5 myScript.sh

Użyj zegarka:

$ watch --interval .30 script_to_run_every_30_sec.sh

Zadania Cron nie można użyć do zaplanowania zadania w odstępach sekundowych. tzn. nie można zaplanować uruchamiania zadania cron co 5 sekund. Alternatywą jest napisanie skryptu powłoki, który używa sleep 5w nim polecenia.

Stwórz skrypt powłoki co 5-5 sekund. Sh za pomocą pętli bash while, jak pokazano poniżej.

$ cat every-5-seconds.sh
#!/bin/bash
while true
do
 /home/ramesh/backup.sh
 sleep 5
done

Teraz uruchom ten skrypt powłoki w tle, nohupjak pokazano poniżej. Spowoduje to kontynuowanie wykonywania skryptu nawet po wylogowaniu z sesji. Spowoduje to wykonanie skryptu powłoki backup.sh co 5 sekund.

$ nohup ./every-5-seconds.sh &

Użyj fcron ( http://fcron.free.fr/ ) - zapewnia ziarnistość w kilka sekund i jest o wiele lepszy i bogatszy w funkcje niż cron (vixie-cron) i stabilny. Robiłem głupie rzeczy, takie jak uruchamianie około 60 skryptów php na jednej maszynie w bardzo głupich ustawieniach i nadal działało!

w reż /etc/cron.d/

nowy utwórz plik excute_per_30s

* * * * * yourusername  /bin/date >> /home/yourusername/temp/date.txt
* * * * * yourusername sleep 30; /bin/date >> /home/yourusername/temp/date.txt

uruchomi crona co 30 sekund

Obecnie używam poniższej metody. Działa bez problemów.

* * * * * /bin/bash -c ' for i in {1..X}; do YOUR_COMMANDS ; sleep Y ; done '

Jeśli chcesz uruchomić co N sekund potem X będzie 60 / N i Y będą N .

Dziękuję Ci.

Zadanie Crontab można wykorzystać do zaplanowania zadania w minutach / godzinach / dniach, ale nie w sekundach. Alternatywa :

Utwórz skrypt, który będzie wykonywany co 30 sekund:

#!/bin/bash
# 30sec.sh

for COUNT in `seq 29` ; do
  cp /application/tmp/* /home/test
  sleep 30
done

Użyj crontab -ei crontab, aby wykonać ten skrypt:

* * * * * /home/test/30sec.sh > /dev/null

Możesz uruchomić ten skrypt jako usługę, restartować co 30 sekund

Zarejestruj usługę

sudo vim /etc/systemd/system/YOUR_SERVICE_NAME.service

Wklej poniższe polecenie

Description=GIVE_YOUR_SERVICE_A_DESCRIPTION

Wants=network.target
After=syslog.target network-online.target

[Service]
Type=simple
ExecStart=YOUR_COMMAND_HERE
Restart=always
RestartSec=10
KillMode=process

[Install]
WantedBy=multi-user.target

Załaduj ponownie usługi

sudo systemctl daemon-reload

Włącz usługę

sudo systemctl enable YOUR_SERVICE_NAME

Uruchom usługę

sudo systemctl start YOUR_SERVICE_NAME

Sprawdź status swojej usługi

systemctl status YOUR_SERVICE_NAME

Dzięki za wszystkie dobre odpowiedzi. Dla uproszczenia podobało mi się rozwiązanie mieszane, z kontrolą crontab i podziałem czasu na skrypcie. Tak właśnie zrobiłem, aby uruchomić skrypt co 20 sekund (trzy razy na minutę). Linia Crontab:

 * * * * 1-6 ./a/b/checkAgendaScript >> /home/a/b/cronlogs/checkAgenda.log

Scenariusz:

cd /home/a/b/checkAgenda

java -jar checkAgenda.jar
sleep 20
java -jar checkAgenda.jar 
sleep 20
java -jar checkAgenda.jar 

napisz jeden skrypt powłoki utwórz plik .sh

nano co 30 sekund. sh

i napisz skrypt

#!/bin/bash
For  (( i=1; i <= 2; i++ ))
do
    write Command here
    sleep 30
done

następnie ustaw cron dla tego skryptu crontab -e

(* * * * * /home/username/every30second.sh)

ten plik .sh wywołania crona co 1 minutę i w poleceniu pliku .sh jest uruchamiany 2 razy w ciągu 1 minuty

jeśli chcesz uruchomić skrypt na 5 sekund, zastąp 30 na 5 i zmień na pętlę w następujący sposób: For (( i=1; i <= 12; i++ ))

kiedy wybierzesz dla dowolnej sekundy, oblicz 60 / sekundę i napisz w pętli For

Właśnie miałem podobne zadanie do wykonania i stosuję następujące podejście:

nohup watch -n30 "kill -3 NODE_PID" &

Potrzebowałem okresowego zabicia -3 (aby uzyskać ślad stosu programu) co 30 sekund przez kilka godzin.

nohup ... & 

Jest to tutaj, aby upewnić się, że nie stracę wykonania zegarka, jeśli stracę powłokę (problem z siecią, awaria systemu Windows itp.)

Spójrz na częsty cron - jest stary, ale bardzo stabilny i możesz zejść do mikrosekund. W tym momencie jedyną rzeczą, którą powiedziałbym przeciwko temu, jest to, że wciąż próbuję wymyślić, jak zainstalować go poza init.d, ale jako natywna usługa systemowa, ale na pewno do Ubuntu 18 działa tylko dobrze nadal używa init.d (odległość może się różnić w późniejszych wersjach). Ma dodatkową zaletę (?) Polegającą na tym, że nie odrodzi innej instancji skryptu PHP, dopóki poprzednia nie zostanie ukończona, co zmniejsza potencjalne problemy z wyciekiem pamięci.

Uruchom w pętli powłoki, przykład:

#!/bin/sh    
counter=1
while true ; do
 echo $counter
 counter=$((counter+1))
 if [[ "$counter" -eq 60 ]]; then
  counter=0
 fi
 wget -q http://localhost/tool/heartbeat/ -O - > /dev/null 2>&1 &
 sleep 1
done