Pomocy: zasady działania crona

Marcin 'Qrczak' Kowalczyk qrczak w knm.org.pl
Czw, 1 Paź 1998, 11:19:38 CEST


hc-cron próbuje tak: jeśli dżob zaznaczony do wykonywania "choćby
z opóźnieniem" wypadł z planu, to próbujemy go odpalić, gdy tylko load
average zejdzie poniżej 0.8. Niby ma to sens...

...tylko że tak się składa, że u mnie jeden proces cały czas wykonuje
sobie obliczenia na najniższym priorytecie i load average _zawsze_ jest co
najmniej 1, tak że cron się tego nie doczeka.

Co gorsza, z niewiadomych przyczyn on takiego dżoba nie będzie próbował
wykonywać nawet o normalnej porze, która nadejdzie, dopóki load average
nie zejdzie poniżej 0.8 albo... przeładujemy crontaba (tzn. touchniemy
go). Na dodatek nie działa opcja, która ma wykonywać danego dżoba
odpowiednią liczbę razy, żeby odrobić wszystkie straty. Ech...

On ma też taki fajny ficzer, że czas określony np. jako @daily oznacza
z grubsza raz dziennie, ale bez określonej godziny - w czasie małej
aktywności systemu. Pasowałoby odpalanie cron.daily domyślnie tak ustawić.
(Różne inne okresy też są.) No ale to jest tak samo wrażliwe na stałe
wysokie load average :-(

Tak więc trzeba by go przerobić; być może dość mocno (jest napisany
w jakiś zagmatwany sposób). ALE JAK? Jak zdefiniować działanie w tych
przypadkach, żeby z jednej strony stałe wysokie load average nie
przeszkadzało, a z drugiej - nie próbował nadrabiać wszystkich zaległości
natychmiast po włączeniu komputera?

Przy okazji mógłbym spróbować naprawić to nadrabianie zaległości
odpowiednią liczbę razy - albo skasować, bo nie widzę przydatności,
zwłaszcza że standardowy cron tego nie ma i jakoś daje się używać.
Na pewno nie powinno zostać tak jak jest: że jest opisane w dokumentacji
i nie działa (tzn. wykonuje go najwyżej raz).

Myślałem o czymś takim, żeby ten próg load average powolutku się podnosił,
żeby zawsze w końcu doszedł do odpowiedniego poziomu. No ale po pierwsze
nie ma jak zdefiniować, od którego momentu ma się podnosić - przecież
cron chodzący bez przerwy przez miesiąc próbuje codziennie odpalać dżoby
@daily korzystając z load average - a po drugie dżob odpalany raz
w miesiącu może się spóźnić nawet kilka dni, a ten odpalany raz na godzinę
już nie bardzo.

Można by z każdym dżobem skojarzyć powolutku rosnący próg load average.
Pojawia się kłopot przy przeładowaniu crontaba, kiedy to wszystkie dżoby
z danego pliku są ładowane na nowo.

(BTW: Mój patch na /etc/crontab.d miał buga - nie przeładowywał crontabów
wszystkich przypadkach, w których powinien.)

Może wpadniemy na jakaś zupełnie inny pomysł, lepszy, która nie przychodzi
mi teraz do głowy? Może w ogóle nie na podstawie load average... ale czego?
W każdym razie trzeba to przystosować do sytuacji, w której to jest stale
dość wysokie. A w ogóle to idealnie by było, gdyby jeśli jest niskie, to
musi tak być przez jakiś czas - żeby nie wystarczyło, że człowiek po
włączeniu komputera przez minutkę nic nie robi, a potem siada do pracy,
ale już dysk przez dziesięć minut rzęzi robiąc updatedb.

Powinno to być jak najbardziej proste i klarowne, a zarazem skuteczne.
Jakoś to wszystko uporządkować... Pomocy!

-- 
 __("<   Marcin Kowalczyk * qrczak w knm.org.pl http://qrczak.home.ml.org/
 \__/       GCS/M d- s+:-- a21 C+++>+++$ UL++>++++$ P+++ L++>++++$ E->++
  ^^                W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP->+ t
QRCZAK                  5? X- R tv-- b+>++ DI D- G+ e>++++ h! r--%>++ y-



Więcej informacji o liście dyskusyjnej pld-devel-pl