Automatyczny restart demona
Seweryn Habdank-Wojewódzki
Czy da sie i co nalezy ustawic w systemie, aby demon, ktory przez
przypadek skonczyl prace zostal uruchomiony na nowo?
Pozdrawiam,
--
|\/\/| Seweryn Habdank-Wojewodzki
\/\/
Professionalism in programming - www.accu.org
Icek
> przypadek skonczyl prace zostal uruchomiony na nowo?
1. da sie
2. trzeba sprawdzic czy sie juz napisalo skrypt sprawdzajacy czy to cos
zyje. Najpewniej uruchamiane z crona ale niekoniecznie
Icek
--
www.StareGry.pl - Najwiekszy polski serwis o tematy ce starych gier
Kamil Jońca
> Witam,
>
> Czy da sie i co nalezy ustawic w systemie, aby demon, ktory przez
> przypadek skonczyl prace zostal uruchomiony na nowo?
Ja bym kombinował z inittabem.
--
KJ
Anyone can make an omelet with eggs. The trick is to make one with none.
Waldek M.
napisał(a):
> Czy da sie i co nalezy ustawic w systemie, aby demon, ktory przez
> przypadek skonczyl prace zostal uruchomiony na nowo?
Inittab, respawn.
Pozdrawiam,
Waldek
Waldek M.
>> Czy da sie i co nalezy ustawic w systemie, aby demon, ktory przez
>> przypadek skonczyl prace zostal uruchomiony na nowo?
>
> 1. da sie
>
> 2. trzeba sprawdzic czy sie juz napisalo skrypt sprawdzajacy czy to cos
> zyje. Najpewniej uruchamiane z crona ale niekoniecznie
Czyli watchdoga? Można, ale lepiej użyć inittaba.
Pozdrawiam,
Waldek
Zygmunt M. Zarzecki
> Czy da sie i co nalezy ustawic w systemie, aby demon, ktory przez
> przypadek skonczyl prace zostal uruchomiony na nowo?
/etc/inittab
zyga
Sebastian Sawicki
źle, uruchamianie _demona_ przez inittab, nie da porzadanego efektu
wznowienia dzialania procesu po jego zakonczeniu, bo respawn jakiego
pewnie chcecie uzyc nie bedzie potrafil sledzic programu ktory wykona
fork() a potem exit() (a to zawiera sie w definicji demona).
Bardziej sluszna metoda, bylo by uzycie np pidof np:
pidof -s demon >/dev/null || /usr/sbin/demon
I uruchamianie tego z crona. Chyba ze istnieje koniecznosc
natychmiastowego uruchomienia procesu po jego terminacji, wtedy wypadalo
by uruchomic demona tak aby sie nie demonizowal i sledzenie jego kodu
wyjscia.
S.
Zygmunt M. Zarzecki
Może i masz rację, z tego co pamiętam jest zestaw programików do tego.
Chyba z bsd się to wywodziło.
zyga
=?ISO 8859-2?Q?Jaros=B3aw?= Siebert
> Czy da sie i co nalezy ustawic w systemie, aby demon, ktory przez
> przypadek skonczyl prace zostal uruchomiony na nowo?
>
najprosciej nie przechodzic w tryb demona tylko uruchomic program przy
pomocy skryptu w nieskonczonej petli.
Czyli cos w stylu:
(while true; do jakis_program ; sleep 1; done) &
ewentualnie jak musi byc jako demon - skorzystac z pidof i w podobnej
petli sprawdzac czy program dziala - jak nie to restartowac usluge.
Przykladowo:
(while true; do sleep 1; (pidof jakis_program || restart_demona); done)&
Oczywiscie dobrze napisany program nie potrzebuje takiej kontroli, ale jak
wiadomo licho nie spi.
pozdrawiam
iu1j4
--
Mirek
Seweryn Habdank-Wojewódzki wrote:
> Witam,
>
> Czy da sie i co nalezy ustawic w systemie, aby demon, ktory przez
> przypadek skonczyl prace zostal uruchomiony na nowo?
>
daemontools
supervise monitors a service. It starts the service and
restarts the service if it dies. Setting up a new service is
easy: all supervise needs is a directory with a run script that
runs the service.
cml
> daemontools
>
> supervise monitors a service. It starts the service and
> restarts the service if it dies. Setting up a new service is
> easy: all supervise needs is a directory with a run script that
> runs the service.
polecam
pozdrawiam serdecznie.
--
(_a/\/\e|_ | .-. | Nawet świnka
cml....dokuro.org | (o o) | potrafi wejść na drzewo
http://dokuro.org | UUU | kiedy jest chwalona
Konrad Kosmowski
>> Czy da sie i co nalezy ustawic w systemie, aby demon, ktory przez przypadek
>> skonczyl prace zostal uruchomiony na nowo?
> Witam, najprosciej nie przechodzic w tryb demona tylko uruchomic program
> przy pomocy skryptu w nieskonczonej petli. Czyli cos w stylu: (while true;
> do jakis_program ; sleep 1; done) &
> ewentualnie jak musi byc jako demon - skorzystac z pidof i w podobnej petli
> sprawdzac czy program dziala - jak nie to restartowac usluge. Przykladowo:
> (while true; do sleep 1; (pidof jakis_program || restart_demona); done)&
Moim zdaniem najlepsza opcja to wspomniana jakaś forma watchdoga np. Zabbix czy
Nagios, który zareaguje restartem usługi przy wystąpieniu zadanych parametrów.
Zauważ, że fakt iż program działa, wcale nie oznacza iż on nadal działa dobrze.
Moim zdaniem należy sprawdzać czy proces, który jest obsługiwany przez program
(bardziej abstrakcyjnie) działa bez problemów, a nie tylko, czy program jest
załadowany do pamięci. Tak na przykład mysql czy httpd mogą Ci zajechać serwer
jakimś leakiem, ale nadal będą przecież działać, przy czym usługa, którą
świadczą będzie działać w ślimaczym tempie bądź wcale.
> Oczywiscie dobrze napisany program nie potrzebuje takiej kontroli,
Nie istnieją takie programy.
W ogóle self healing to ciekawy temat. Inne systemy uniksowe (Windows też) mają
coś takiego jak restart wbudowane. Np. SVC framework z Solarisa czy launchd z
MacOS X. Na Linuksa przypuszczam (ale nie sprawdzałem) te nowe
systemy/zamienniki init mogą mieć takie funkcje, tzn. np. init-ng czy coś
podobnego (tego jest kilka różnych).
--
+ ' .-. .
, * ) )
http://kosmosik.net/ . . '-' . kK
=?ISO 8859-2?Q?Jaros=B3aw?= Siebert
done)&
>
> Moim zdaniem najlepsza opcja to wspomniana jakaś forma watchdoga np.
> Zabbix czy Nagios, który zareaguje restartem usługi przy wystąpieniu
> zadanych parametrów.
parametrow. Czasami trudno przewidziec jakie zasoby systemowe bedzie
pochlaniac baza danych po nieprzerwanym kilkuletnim dzialaniu.
> Zauważ, że fakt iż program działa, wcale nie oznacza
> iż on nadal działa dobrze.
Racja, jednak nie mozna zakladac ze piszemy cos co nie dziala prawidlowo.
Jesli sa problemy z wyciekami - nalezy ograniczyc stosowanie dynamicznego
przydzielania pamieci do niezbednego minimum. Reagowac jedynie na znane
scenuriasze a wszystkie inne omijac konczac dzialanie aplikacji.
> Moim zdaniem należy sprawdzać czy proces, który
> jest obsługiwany przez program (bardziej abstrakcyjnie) działa bez
> problemów, a nie tylko, czy program jest załadowany do pamięci.
Owszem - to jest optymalne rozwiazanie - ale pod warunkiem, ze programista
jest w stanie obrac sensowne parametry. Nie ma sie co oszukiwac - jak brak
doswiadczenia to takie zabiegi beda wzglednie skuteczne. Pozatym -
monitoring lepiej wprowadzac stopniowo i bardziej poswiecic czas na wlasciwe
programowanie.
> Tak na
> przykład mysql czy httpd mogą Ci zajechać serwer jakimś leakiem, ale nadal
> będą przecież działać, przy czym usługa, którą świadczą będzie działać w
> ślimaczym tempie bądź wcale.
Tu nalezaloby dodac dodatkowo wlasciwa polityke czyszczenia logow, by
przypadkiem system nie odmowil wspolpracy z braku przestrzeni dyskowej.
Przy mysql mialem kiedys problem z liczba obslugiwanych polaczen rownolegle
i raczej na owczesnym etapie zaawansowania zaden system monitoringu by mi
nie pomogl. Jedynym rozwiazaniem bylo przeprojektowanie aplikacji.
>> Oczywiscie dobrze napisany program nie potrzebuje takiej kontroli,
>
> Nie istnieją takie programy.
Przy odrobinie samodyscypliny da sie napisac program bez wyciekow,
dzialajacy w sposob przewidywalny i latwy w testowaniu. Jedyne
mechanizmy zapewniajace nieprzerwane dzialanie aplikacji to
opisane skrypty z zapetlonymi wywolaniami programow.
Oczywiscie pisze o swoich programach - bo jesli chodzi o programy dostawcow
trzecich to z braku wiedzy o ich sposobie dzialania monitoring sie przydaje.
> W ogóle self healing to ciekawy temat. Inne systemy uniksowe (Windows też)
> mają coś takiego jak restart wbudowane. Np. SVC framework z Solarisa czy
> launchd z MacOS X. Na Linuksa przypuszczam (ale nie sprawdzałem) te nowe
> systemy/zamienniki init mogą mieć takie funkcje, tzn. np. init-ng czy coś
> podobnego (tego jest kilka różnych).
Jak taki system kontroli/monitoringu za bardzo sie rozrosnie - to sam bedzie
stanowil znaczne obciazenie dla serwera. Poza tym jest to dodatkowe zrodlo
potencjalnych problemow i mozliwych awarii.
Moim zdaniem nalezy wybierac rozwiazania proste - na miare aktualnych
potrzeb.
Tak przy okazji tego tematu - mialem niedawno sytuacje, gdy procesor byl
doslownie zdosowany przez konflikty przerwan spowodowanych brakiem
synchronizacji obslugi poszczegolnych portow szeregowych.
W serwerze jest 8 portow szeregowych, dzialajacych niezaleznie pod kontrola
8 aplikacji. Porty szeregowe dzielily przerwania w parach, tzn 2 porty na 1
przerwanie. Aplikacje odbieraly od urzadzen przez rs232 pakiety w ilosci
okolo 60 ramek/s (poprawnych). To byla skutecznosc pojedynczego urzadzenia.
Przy obsludze wszystkich spadla do okolo 6 poprawnych ramek/s
(przy czym wymagana skutecznosc to 1 ramka na kilka s)
Jedyne co mozna bylo zaobserwowac to wzrost zucycia CPU poprzez procesy
obslugujace port szeregowy (od 0.3% do okolo 20% na proces) na przestrzeni
wielu godzin. Logowanie przez ssh bylo spowolnione i pozostale operacje
rowniez. Oczywiscie aplikacje dzialaly prawidlowo - system byl jak
najbardziej uzywalny i jedyne co kazalo zwrocic na siebie uwage to duza
liczba ERR w /proc/interrupts (siegajaca milionow). Po zsynchronizowaniu
dzialania aplikacji obslugujacych porty szeregowe i uszeregowaniu ich
obslugi - problem przestal istniec.
pozdrawiam
iu1j4
--
Waldek M.
> Może i masz rację, z tego co pamiętam jest zestaw programików do tego.
> Chyba z bsd się to wywodziło.
Może Demon tools Bernsteina? Ponoć są świetne, ale nie
używałem, więc informacje mam z drugiej ręki.
Pozdrawiam,
Waldek
Konrad Kosmowski
>> Zauważ, że fakt iż program działa, wcale nie oznacza iż on nadal działa
>> dobrze.
> Racja, jednak nie mozna zakladac ze piszemy cos co nie dziala prawidlowo.
:)))
Właśnie to TRZEBA zakładać. Skoro zakładasz, że coś działa prawidłowo to
przecież cały ten wątek nie ma uzasadnienia.
(...)
>> Moim zdaniem należy sprawdzać czy proces, który jest obsługiwany przez
>> program (bardziej abstrakcyjnie) działa bez problemów, a nie tylko, czy
>> program jest załadowany do pamięci.
> Owszem - to jest optymalne rozwiazanie - ale pod warunkiem, ze programista
> jest w stanie obrac sensowne parametry. Nie ma sie co oszukiwac - jak brak
> doswiadczenia to takie zabiegi beda wzglednie skuteczne. Pozatym - monitoring
> lepiej wprowadzac stopniowo i bardziej poswiecic czas na wlasciwe
> programowanie.
Najlepiej być bogatym i pięknym i młodym.
>> Tak na przykład mysql czy httpd mogą Ci zajechać serwer jakimś leakiem, ale
>> nadal będą przecież działać, przy czym usługa, którą świadczą będzie działać
>> w ślimaczym tempie bądź wcale.
> Tu nalezaloby dodac dodatkowo wlasciwa polityke czyszczenia logow, by
> przypadkiem system nie odmowil wspolpracy z braku przestrzeni dyskowej.
No, a woda jest mokra.
> Przy mysql mialem kiedys problem z liczba obslugiwanych polaczen rownolegle i
> raczej na owczesnym etapie zaawansowania zaden system monitoringu by mi nie
> pomogl.
A ile systemów monitoringu widziałeś? :) BTW z MySQL to chyba wszyscy mieli i
miewają problemy, więc to nie jest żadna nowość.
> Jedynym rozwiazaniem bylo przeprojektowanie aplikacji.
Zakładając, że administrator jest od tego aby projektować aplikacje - nie jest.
>>> Oczywiscie dobrze napisany program nie potrzebuje takiej kontroli,
>> Nie istnieją takie programy.
> Przy odrobinie samodyscypliny da sie napisac program bez wyciekow, dzialajacy
> w sposob przewidywalny i latwy w testowaniu.
No to po co założyłeś ten wątek i skąd te pytanie? Przecież wszystkie programy
działają bezbłędnie, więc co chcesz restartować?
> Jedyne mechanizmy zapewniajace nieprzerwane dzialanie aplikacji to opisane
> skrypty z zapetlonymi wywolaniami programow.
Niejedyne. Patrz niżej.
(...)
>> W ogóle self healing to ciekawy temat. Inne systemy uniksowe (Windows też)
>> mają coś takiego jak restart wbudowane. Np. SVC framework z Solarisa czy
>> launchd z MacOS X. Na Linuksa przypuszczam (ale nie sprawdzałem) te nowe
>> systemy/zamienniki init mogą mieć takie funkcje, tzn. np. init-ng czy coś
>> podobnego (tego jest kilka różnych).
> Jak taki system kontroli/monitoringu za bardzo sie rozrosnie - to sam bedzie
> stanowil znaczne obciazenie dla serwera.
Czy masz w ogóle zielone pojęcie o czym ja wyżej napisałem. :) Próbowałeś,
któregokolwiek z tych systemów? Taki (który restartuje po padzie w
przeciwieństwie do sysvinit) system od kilkunastu lat bez problemu działa w
Windows NT np. (Services) i praktycznie nie ma to żadnego narzutu. Chodzi po
prostu o to, że sysvinit działa na zasadzie fire-and-forget, czyli odpala i w
dupie ma czy coś dalej działa. Zwróciłem Ci tylko uwagę, że są NOWE
systemy/zamienniki init, które potrafią monitorować czy proces działa, więc nie
trzeba do nich jakiś przyczłap pisać.
(...)
> Moim zdaniem nalezy wybierac rozwiazania proste - na miare aktualnych
> potrzeb.
Znowu zakładasz coś bez znajomości tematu. :) W/w systemy (no może poza SVC
framework) mają niższy poziom skomplikowania niż to co masz obecnie w swoim
linuksie czyli fafnaście różnych metod wywoływania programów...
=?ISO 8859-2?Q?Jaros=B3aw?= Siebert
>
>> Jedynym rozwiazaniem bylo przeprojektowanie aplikacji.
>
> Zakładając, że administrator jest od tego aby projektować aplikacje - nie
> jest.
>
no tak, Ty z punktu widzenia administratora - ja programisty ;)
Tak na maryginesie - odpisujac na ten temat myslalem ze jest na grupie
*.programowanie i do tego sie odnioslem.
>> Przy odrobinie samodyscypliny da sie napisac program bez wyciekow,
>> dzialajacy w sposob przewidywalny i latwy w testowaniu.
>
> No to po co założyłeś ten wątek i skąd te pytanie? Przecież wszystkie
> programy działają bezbłędnie, więc co chcesz restartować?
Nie ja zakladalem watek - jedynie udzielilem jednej z mozliwych odpowiedzi.
>> Jedyne mechanizmy zapewniajace nieprzerwane dzialanie aplikacji to
>> opisane skrypty z zapetlonymi wywolaniami programow.
>
> Niejedyne. Patrz niżej.
jedyne, ktore dla wlasnego spokoju stosuje i sie sprawdzaja.
>> Jak taki system kontroli/monitoringu za bardzo sie rozrosnie - to sam
>> bedzie stanowil znaczne obciazenie dla serwera.
>
> Czy masz w ogóle zielone pojęcie o czym ja wyżej napisałem. :) Próbowałeś,
> któregokolwiek z tych systemów? Taki (który restartuje po padzie w
> przeciwieństwie do sysvinit) system od kilkunastu lat bez problemu działa
> w Windows NT np. (Services) i praktycznie nie ma to żadnego narzutu.
> Chodzi po prostu o to, że sysvinit działa na zasadzie fire-and-forget,
> czyli odpala i w dupie ma czy coś dalej działa. Zwróciłem Ci tylko uwagę,
> że są NOWE systemy/zamienniki init, które potrafią monitorować czy proces
> działa, więc nie trzeba do nich jakiś przyczłap pisać.
Akurat nie do tych zamiennikow sie odnioslem. Moim zdaniem nie wszedzie jest
sens monitorowac zuzycie procesora czy pamieci przez proces. Do tego jak sie
domyslam moze sie nadac zwykly ulimit czy pam.
>
>> Moim zdaniem nalezy wybierac rozwiazania proste - na miare aktualnych
>> potrzeb.
>
> Znowu zakładasz coś bez znajomości tematu. :) W/w systemy (no może poza
> SVC framework) mają niższy poziom skomplikowania niż to co masz obecnie w
> swoim linuksie czyli fafnaście różnych metod wywoływania programów...
>
w koncu grupa dotyczy linuksa - wiec tego sie trzymajmy.
Na proste pytanie padlo kilka prostych odpowiedzi i chyba nie ma sensu robic
z tego wiekszego dramatu.
W koncu pytanie dotyczylo tylko automatycznego restartu demona, co mozna
zrealizowac przy pomocy jednolinijkowego skryptu nie martwiac sie o nic
wiecej.
Jeszcze raz tylko przypominam, ze moje podejscie jest nie z punktu widzenia
administratora, a programisty.
pozdrawiam
iu1j4
--
Icek
widzenia
> administratora, a programisty.
znaczy ze musi byc gotowiec bo administrator nie wklepie jednolinijkowca ?
;P
Konrad Kosmowski
>> Jeszcze raz tylko przypominam, ze moje podejscie jest nie z punktu widzenia
>> administratora, a programisty.
> znaczy ze musi byc gotowiec bo administrator nie wklepie jednolinijkowca ?
> ;P
Znaczy, że administrator to taki cieć, który ma utrzymać system w ruchu w
okresie eksploatacji. Projektuje i testuje się system przed jego odbiorem,
zdarza się tak, że po odbiorze coś jest nie tak - ale tutaj również rolą
administratora nie jest łatanie aplikacji (i często w ogóle nie ma takiej
możliwości).
Konrad Kosmowski
>> Czy masz w ogóle zielone pojęcie o czym ja wyżej napisałem. :) Próbowałeś,
>> któregokolwiek z tych systemów? Taki (który restartuje po padzie w
>> przeciwieństwie do sysvinit) system od kilkunastu lat bez problemu działa w
>> Windows NT np. (Services) i praktycznie nie ma to żadnego narzutu. Chodzi
>> po prostu o to, że sysvinit działa na zasadzie fire-and-forget, czyli odpala
>> i w dupie ma czy coś dalej działa. Zwróciłem Ci tylko uwagę, że są NOWE
>> systemy/zamienniki init, które potrafią monitorować czy proces działa, więc
>> nie trzeba do nich jakiś przyczłap pisać.
> Akurat nie do tych zamiennikow sie odnioslem. Moim zdaniem nie wszedzie jest
> sens monitorowac zuzycie procesora czy pamieci przez proces.
Oczywiście. Ja tylko zwróciłem uwagę, że taki sposób monitorowania (czy proces
istnieje na liście) jest dosyć prymitywny. Mnie np. nie obchodzi czy proces
istnieje na liście czy nie - natomiast obchodzi mnie czy dana *usługa* działa
poprawnie dla jej beneficjenta. :)
> Do tego jak sie domyslam moze sie nadac zwykly ulimit czy pam.
Pewnie tak.
>>> Moim zdaniem nalezy wybierac rozwiazania proste - na miare aktualnych
>>> potrzeb.
>> Znowu zakładasz coś bez znajomości tematu. :) W/w systemy (no może poza SVC
>> framework) mają niższy poziom skomplikowania niż to co masz obecnie w swoim
>> linuksie czyli fafnaście różnych metod wywoływania programów...
> w koncu grupa dotyczy linuksa - wiec tego sie trzymajmy. Na proste pytanie
> padlo kilka prostych odpowiedzi i chyba nie ma sensu robic z tego wiekszego
> dramatu.
Żadna z tych odpowiedzi moim zdaniem nie jest prawidłowym podejściem do tematu.
> W koncu pytanie dotyczylo tylko automatycznego restartu demona, co mozna
> zrealizowac przy pomocy jednolinijkowego skryptu nie martwiac sie o nic
> wiecej.
No właśnie o to chodzi, że im więcej takich przyczłap tym system będzie
bardziej podatny na błędy. Moim zdaniem ponownym odpalaniem procesów powinien
się zająć sam system init.
> Jeszcze raz tylko przypominam, ze moje podejscie jest nie z punktu widzenia
> administratora, a programisty.
To nie ma w ogóle związku z programowaniem.