Zapobiegaj uruchamianiu zduplikowanych zadań cron

Zaplanowałem uruchamianie zadania cron co minutę, ale czasami skrypt trwa dłużej niż minutę i nie chcę, aby zadania zaczęły się „nakładać” na siebie. Myślę, że jest to problem współbieżności - tzn. Wykonywanie skryptu musi się wykluczać.

Aby rozwiązać problem, sprawiłem, że skrypt szukał określonego pliku („ lockfile.txt ”) i kończy działanie, jeśli istnieje, lub touchjeśli nie. Ale to kiepski semafor! Czy jest jakaś najlepsza praktyka, o której powinienem wiedzieć? Czy zamiast tego powinienem napisać demona?

Istnieje kilka programów, które automatyzują tę funkcję, usuwają irytację i potencjalne błędy związane z robieniem tego samemu, a także unikają problemu przestarzałej blokady, używając również stada za sceną (co jest ryzykowne, jeśli używasz tylko dotyku) . Kiedyś używałem lockruni lckdokiedyś, ale teraz jest flock(1) (w nowych wersjach util-linux), co jest świetne. Jest naprawdę łatwy w użyciu:

* * * * * /usr/bin/flock -n /tmp/fcj.lockfile /usr/local/bin/frequent_cron_job

Najlepszym sposobem w powłoce jest użycie stada (1)

(
  flock -x -w 5 99
  ## Do your stuff here
) 99>/path/to/my.lock

Właściwie flock -nmoże być użyte zamiast lckdo*, więc będziesz używać kodu od programistów jądra.

Opierając się na przykładzie womble , napiszesz coś takiego:

* * * * * flock -n /some/lockfile command_to_run_every_minute

BTW, patrząc na kod, wszystko flock, lockruni lckdorobić dokładnie to samo, więc to tylko kwestia co jest najłatwiej dostępne.

Możesz użyć pliku blokady. Utwórz ten plik po uruchomieniu skryptu i usuń go po zakończeniu. Skrypt, zanim uruchomi swoją główną procedurę, powinien sprawdzić, czy plik blokady istnieje i postępować odpowiednio.

Pliki blokujące są używane przez skrypty startowe oraz wiele innych aplikacji i narzędzi w systemach uniksowych.

Nie określiłeś, czy chcesz, aby skrypt czekał na zakończenie poprzedniego uruchomienia, czy nie. Poprzez „Nie chcę, aby zadania zaczęły się„ nakładać ”jeden na drugi, myślę, że sugerujesz, że chcesz, aby skrypt został zamknięty, jeśli jest już uruchomiony,

Więc jeśli nie chcesz polegać na lckdo lub podobnym, możesz to zrobić:

PIDFILE=/tmp/`basename $0`.pid

if [ -f $PIDFILE ]; then
  if ps -p `cat $PIDFILE` > /dev/null 2>&1; then
      echo "$0 already running!"
      exit
  fi
fi
echo $$ > $PIDFILE

trap 'rm -f "$PIDFILE" >/dev/null 2>&1' EXIT HUP KILL INT QUIT TERM

# do the work

Może to również oznaczać, że robisz coś złego. Jeśli twoje zadania działają tak blisko i tak często, być może powinieneś rozważyć usunięcie ich z programu i uczynienie z niego programu w stylu demona.

Twój demon cron nie powinien wywoływać zadań, jeśli poprzednie instancje nadal działają. Jestem programistą jednego demona cron dcron i staramy się temu zapobiec. Nie wiem, jak Vixie cron lub inne demony sobie z tym radzą.

Poleciłbym użycie polecenia run-one - o wiele prostsze niż radzenie sobie z blokadami. Z dokumentów:

run-one to skrypt otoki, który uruchamia nie więcej niż jedno unikalne wystąpienie jakiegoś polecenia z unikalnym zestawem argumentów. Jest to często przydatne w cronjobs, gdy nie chcesz, aby działała więcej niż jedna kopia na raz.

run-this-one jest dokładnie tak samo jak run-one, z tym wyjątkiem, że użyje pgrep i kill do znalezienia i zabicia wszelkich uruchomionych procesów należących do użytkownika i dopasowania poleceń i argumentów docelowych. Zauważ, że run-this-one blokuje się podczas próby zabicia pasujących procesów, dopóki wszystkie pasujące procesy nie zostaną zakończone.

run-one-stale działa dokładnie tak, jak run-one, z tym wyjątkiem, że odradza się „COMMAND [ARGS]” za każdym razem, gdy kończy się polecenie COMMAND (zero lub zero).

keep-one-running to alias do ciągłego uruchamiania.

run-one-dopóki-sukces działa dokładnie tak, jak run-one-stale, z tym wyjątkiem, że odradza się „COMMAND [ARGS]”, dopóki COMMAND nie zakończy się pomyślnie (tzn. zakończy zero).

run-one- till -failure działa dokładnie tak, jak run-one-stale, z tym wyjątkiem, że odradza się „COMMAND [ARGS]”, dopóki COMMAND nie zakończy się niepowodzeniem (tzn. zakończy się niezerowo).

Teraz, gdy systemd jest już dostępny, istnieje inny mechanizm planowania w systemach Linux:

ZA systemd.timer

W /etc/systemd/system/myjob.servicelub ~/.config/systemd/user/myjob.service:

[Service]
ExecStart=/usr/local/bin/myjob

W /etc/systemd/system/myjob.timerlub ~/.config/systemd/user/myjob.timer:

[Timer]
OnCalendar=minutely

[Install]
WantedBy=timers.target

Jeśli jednostka serwisowa już aktywuje się, gdy następny timer zostanie aktywowany, to kolejne wystąpienie usługi nie zostanie uruchomione.

Alternatywa, która uruchamia zadanie raz podczas rozruchu i minutę po zakończeniu każdego uruchomienia:

[Timer]
OnBootSec=1m
OnUnitInactiveSec=1m 

[Install]
WantedBy=timers.target

Stworzyłem jeden słoik, aby rozwiązać taki problem, jak uruchomione duplikaty cronów, może to być cron java lub shell. Wystarczy podać nazwę crona w Duplicates.CloseSessions („Demo.jar”), aby wyszukać i zabić istniejący pid dla tego crona oprócz bieżącej. Wdrożyłem metodę, aby to zrobić. Zaimek ciągu = ManagementFactory.getRuntimeMXBean (). GetName (); Ciąg pid = proname.split („@”) [0]; System.out.println („Current PID:” + pid);

            Process proc = Runtime.getRuntime().exec(new String[]{"bash","-c"," ps aux | grep "+cronname+" | awk '{print $2}' "});

            BufferedReader stdInput = new BufferedReader(new InputStreamReader(proc.getInputStream()));
            String s = null;
            String killid="";

            while ((s = stdInput.readLine()) != null ) {                                        
                if(s.equals(pid)==false)
                {
                    killid=killid+s+" ";    
                }
            }

A następnie zabij killid string ponownie poleceniem powłoki

Odpowiedź Philipa Reynoldsa rozpocznie wykonywanie kodu po upływie czasu oczekiwania 5 sekund bez uzyskania blokady. Obserwowanie Flocka wydaje się nie działać. Zmodyfikowałem odpowiedź @Philip Reynolds na

(
  flock -w 5 -x 99 || exit 1
  ## Do your stuff here
) 99>/path/to/my.lock

aby kod nigdy nie był wykonywany jednocześnie. Zamiast tego po upływie 5 sekund proces zakończy się na 1, jeśli do tego czasu nie uzyska blokady.