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
