Miroslav Lachman wrote on 12. 3. 2020 16:45:
Zil jsem v domeni, ze kdyz se prerusi SSH spojeni, tak proces, ktery byl
spusten uzivatelem skrz to SSH spojeni, se taky ukonci.
Hacek je zakopany v presnem popisu.
A ten se ti dokonce (asi neumyslne) podaril. Skutecne - *proces* se
ukonci. Myslim aktivne - musi to udelat on. No a nektery proces se
proste neukonci.
Tak ja to radsi popisu jinak.
Kdyz spadne SSHD, proces by od nej mel dostat signal SIGHUP. Signal je
procesem prijat a obslouzen, pricemz defaultni obsluzna rutina aktivne
ukonci proces (sama sebe). Ale konkretni proces nemusi nechat reagovat
defaultni obsluznou rutinu, muze instalovat vlastni nebo aktivovat
"igoruj" obsluhu signalu ...
Rodicem toho procesu se stal PID 1 (init).
Kdyz umre rodicovsky proces a child neskonci, pak se jeho rodicem stava
init.
A jak tomu zabranit?
Pokud ...
1. nejde o chybu SSHD (dokaze zabranit tomu, aby se pri jeho konci detem
SIGHUP poslal)
2. nejde o chybu systemu (odeslany signal se nedoruci)
pricemz
na tyhle chyby to nevypada, kdyz u jinych procesu to funguje spravne
tak jde o
3. chybu procesu, ktery se rozhodne se neukoncovat.
Mozne reseni:
a) oprava procesu aby se takhle nechoval (muze to byt chyba PHP nebo
dusledek vady interpretovaneho PHP kodu)
nebo
b) napsat wrapper, spoustet ze sshd ten a ktery teprve bude volat
postizeny proces a ktery bud etransparentni az na ten SIGHUP, ktery
nebude dolu predavat 1:1 a misto nej posle jiny signal, na ktery proces
reagovat ochotny je, propadne SIGKILL, ktery sam obslouzit (a tedy
ignorovat) nemuze.
Zrovna v tomhle pripade bych potreboval, aby ten proces taky umrel. I
kdyz mi neco naseptava, ze neni normalni ani to, ze tam ten proces
zustane bezet klidne 20 hodin a zere veskery CPU (tzn. je tam neco hodne
spatne)
Zrejme dalsi prizmak vady toho SW.
Tak mu omez maximalni dovoleny spotrebovany cas procesoru. Po prelezeni
sift limitu dostane SIGXCPU coz ho defaultne taky ukonci, ale i tohle
muze ignorovat. Prelezeni hard limitu by ale uz prezit nemel.
Dan
--
FreeBSD mailing list (users-l@freebsd.cz)
http://www.freebsd.cz/listserv/listinfo/users-l
