Re: reparenting procesu po preruseni ssh spojeni
Miroslav Lachman wrote on 25. 3. 2020 14:59: 3. chybu procesu, ktery se rozhodne se neukoncovat. Kdyz je v systemu takhel zaseknuty proces, je nejaka moznost, jak se k nemu pripojit nejakym debugovacim nastrojem a zjistit, proc / na cem se zaseknul? V tomhle jsem absolutne nezkuseny... Debuggery jsou schopny se pripojit i k bezicimu procesu. A pokud je binar s debugovacima informacema a mas k dispozici zdrojaky ze kterych by prelozen, budou ti umoznovat debugovani i v zdrojovem kody high-level jazyka ve kterym byl napsan. Hackem muze byt: 1. proces pouziva sdilene knihovny a akualne se nachazi v nejaek takove. Neni to problem pokud vyse ivedene plati i pro dotcenou knihovnu (je prelozena s debugovacimi informacmei a mas zdrojaky). 2. proces provedl syscall a ten dosud neskoncil (tzn. provadi se in-kernel kod). Tak mu omez maximalni dovoleny spotrebovany cas procesoru. Pod stejnym uzivatelem se na tom serveru spousti vice uloh. Limit je na kazdy proces. Funguje tohle tak, ze se ten limit z login.conf bude aplikovat jen na ten konkretni proces, ktery presahne ten CPU time? Tzn. opravdu to killne jen tenhle vadny proces? Signal SIGXCPU dostane jen proces, ktery prekrocil svuj soft limit. Ale nemusis to nutne globalne nastavovat v login.conf - na prikazove radce na to je prikaz ulimit, dalsi moznost je, ze si limit proces nastavi sam (v PHP funkce posix_setrlimit) RESOURCE LIMITS Name Type Notes Description cputime time CPU usage limit. "time" ma jakou jednotku? Pocet sekund, ktere muze proces sezrat na CPU a pak dojde k jeho ukonceni? setrlimit to bere v sekundach, takze predpokladam, ze to tady bude stejne. Uz je to moc davno, co jsem to naposled pouzil ... Dan -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: reparenting procesu po preruseni ssh spojeni
Jelikoz se problem dnes zase vyskytl nekolikrat po sobe, tak se k tomuto tematu vracim... Dan Lukes wrote on 2020/03/14 09:49: 3. chybu procesu, ktery se rozhodne se neukoncovat. Kdyz je v systemu takhel zaseknuty proces, je nejaka moznost, jak se k nemu pripojit nejakym debugovacim nastrojem a zjistit, proc / na cem se zaseknul? V tomhle jsem absolutne nezkuseny... 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. Ten wrapper by taky byla moznsot, ale nejsem si jisty, jestli tu zmenu akceptuje klient (budou muset zmenit neco na sve strane s Jenkinsem) 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. Pod stejnym uzivatelem se na tom serveru spousti vice uloh. Funguje tohle tak, ze se ten limit z login.conf bude aplikovat jen na ten konkretni proces, ktery presahne ten CPU time? Tzn. opravdu to killne jen tenhle vadny proces? V manualu k login.conf je RESOURCE LIMITS Name Type Notes Description cputimetimeCPU usage limit. "time" ma jakou jednotku? Pocet sekund, ktere muze proces sezrat na CPU a pak dojde k jeho ukonceni? Mirek -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: reparenting procesu po preruseni ssh spojeni
Dne 14.3.2020 v 9:49 Dan Lukes napsal(a): 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. Pokud bychom se chtěli hrabat v nechutných podrobnostech, tak celkem běžné je, že proces zrovna v tu dobu, kdy mu přišel SIGHUP dělá nějaké systémové volání, které trvá dlouho (čtení z pásky). Systém takový signál nepřijme, ale "odloží" ho na dobu, kdy bude proces zase ve "svém" kontextu. Existují volání, která se dokáží docela slušně pokazit, ale to se pak celkem dost pozná, že plní systémový log. Třeba o poškozeném disku nebo tak. To ale asi nebude tvůj případ. -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: reparenting procesu po preruseni ssh spojeni
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
