reparenting procesu po preruseni ssh spojeni

[Dan Lukes]

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