Ginace pppd

[Tomasz Kłoczko]

On Wed, 29 Mar 2000, Marcin Bohosiewicz wrote:

> Witam,
> 
> Po raz kolejny pisze o tym samym. Otoz zainstalowalemPLD na kilku
> maszynkach ktore robia za routery dla lacz stalych i we wszystkich
> mam ten sam objaw: pppd ginie jak dluzej lacze jest rozpiete.
> W logu widac, ze persist dziala, ale po jakims czasie pppd robi Exit
> i znika. Podejrzewam, ze jest to spowodowane tym, ze obsluga ppp jest w
> module i kernel czasem miewa problemy z jego zaladowaniem jak z portu
> szeregowego dojda smieci (np. jak modem Goramo ma rozpieta linie).
> W logu widac"can't load module char-major-<bardzo_duza_liczba>).
> 
> Tymczasowo wrzucilem w cron'a skrypt sprawdzajacy obecnosc pppd 
> i przeladowujacy ifdown/ifup ale to tylko obejscie.

Właśnie dzisiaj myślałem nad czymś co jest bardzo blisko zwiazane z
powyższym.

Ab obvo ..
Otóż generalnie pppd pracujące na potrzeby łacz dzierżawionych uruchamia
się na dwa sposoby. Pierwszy tadycyjny polegajacy na urucchamianiu poprzez
inita i tenże init o ile pppd wyleci uruchamia kolejną instancję
pppd. Drugi sposób "nowy" to to co przywędrowało min ze skryptami
startowymi RH. Ten sposób ma pewne widoczne upierdliwości. Otóż do
zarządzania takim połaczneiem angażowany jest dodatkowy shell, a jak widać
i tak nie jest to niezawodne.

Teraz można się spróbować jeszcze przyjrzeć czemuś innemu co mnie
osobiście od kilkunastu dni trapi i spokojnie myśleć nie daje. Otóż jeżeli
przyjrzeć sie to to co robi init jest proste i wygodne ale jednoczesnie
niewygodne w zarządzaniu opartym o styl SySV. Każde dodatkowe pppd wymaga
bezpośredniej modyfikacji /etc/inittab i ciężko poddaje sie to
modularyzacji. Z drugiej strony .. odpalanie pppd i pilnoewanie tego czy
cos pracuje to tylko szczególny przypadek czegoś czemu podlegać powinny w
zasadzie wszystkie skrypty startowane/stopowane na konkretnym init
level.
O co mi chodzi ? ano o to, żeby skonstruować coś co miałoby zalety inita w
dziedzinie podnoszenia i pilnowania tego co padło, a także logowanai
takich zdażeń, a jednocześnie nie wymagałoby stosowanai jednego pliku
konfiguracyjnego. Do pewneo stopnia rejestracja rzeczy która ma być
uruchamiana i pilnowan czy jest uruchomiona powinna sie odbyuwać
dymamicznie. Można sobie wyobrazić czy to inita czy to program który wiszi
na inicie i kory ma pewne poddobne funkcje do inita jeśli chodzi o
programy które ma nadzorować który to program przyjmowałby zlecenia
uruchamiania poprzez named pipe czy też unix sockets.

Modyfikowanie tutaj inita wydaje sie dość ryzykowne gyż ten program
stanowi pewną zaporę przy securelevel czy też pełni inne funkcje i już sam
kernel wykorzystuje tu to, że proces o PID=1 to jest init i że ma on
konkretne zadania do wykonywania.
Dlatego skompletowanie narzedzia które pilnowałoby tego czy np. jest
uruchomiony named, konkretne pppd czy inne rzeczy na podobnych zasadach
jak to robi init wydaje się dość logiczne. Narzędzie takie zbudować
powinno byuć bardzo łatwo gdyż wystarczyłoby wyuciać cżęść kodu inita i
załatwić wyłącznie sprawę komunikacji z czymś takim.
Rozwiązanie takie miałoby też tą dobrą stronę, że na potrzeby pilnowania
poszczególnych procesów nie anagażowany byłby jakikolwiek
shell. Rozwiazania pilnujące urucjhamianych p[rocesów są spotykane w
róznych miejscach ale głównie mają postać skryptów włąsnie w sh (jak to z
initscripts na potrzeby pppd) czy w perlu.

Głownie chodzi o to żeby całóść drzewa procesów w systemnie miała postać:

init-+
     +-task_mgr-+
                +-named
                +-pppd
                +-.
                +-.
                .
                .

i druga sprawa to to żeby takie rozwiazanie do pewnego stopnia
wykorzystywało funkcje jakie są wykonywane przez rc-scripts, to znaczy że
np. rc3.d/K*named żeby wyrejestrowywało z bierzacej listy procesów
pilnowanycjh przez task_mgr samego nameda i żeby sam task_mgr zajaćł juz
sie sam zabiciem procesu o ile dostanie takie zlecenie.
Kolejna sprawa to załatwienie podejmowanai jakis dodatkowych apkcji przez
task_mgr o ile cos się stanie z pilnownym procesem jak choćby wykonanie
jakiegoś programu/skryptu o ile zginie proces i bezie musiał być on
podnoszony (np. po to żeby wysłąć SMSa) i oczywiście logowanei wszystkich
czynnosci jakie czy to są zlecane czy też samodzielnie podejmowane.

Powyzsze to tylko założenia i pewnei szkielet. Wydaje mi się ,ze tą
problematyke mozan dalej dążyć w celu opracowanai porządnych założeń
takiego wyspecjalizowanego mnarzędzia któe bedzie miało na pewno szersze
zastosowanie (przecieś interfejsy ATM też mają własne narzędzi króre są
uruchamiana per interfejs do lan emulation i które też mogłby podlegać
kontroli takiemu narzędziu)

tak czy inaczej obecne rozwiazanie zwiazane z zarządznie pppd w obecnych
skryptach startowych uważam za niewystarczające i co wiecej uważam, że
jest to fragment pewnego zagadnienia które ma dalego szersze znaczenie i
zastosowanie.

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*


___________________________
polish  linux  distribution
-> http://lists.pld.org.pl/