Komiks turnoff.us: Proč nepoužívat SIGKILL (diskuse)

[lertimir]

Tedy ten web je úžasný.

[Michal Kubeček]

Že by důstojný nástupce Hacklese a Kernel Panic?

[Ovocníček]

Tedy tomhle komiksu už nemůžu použít ani jedno z toho.

[xkucf03]

Tak snad leda kill -PLEASERIP 1234

[little.owl]

+1

To je hnus takhle emotivne manipulovat s lidmi ... .

[Marián Kyral]

No problém je, že někdy SIGTERM nezafunguje. A někdy člověk ani nechce, aby process ovlivňoval svědky

[pc2005]

Přesně .

Jinak pokud by byl proces v kernel sekci, tak ho neovlivní ani SIGKILL.

[pc2005]

Powershell . Akorát je na můj vkus moc orientovanej na Javu :-/.

[trekker.dk]

Teď v poslední době jsem viděl pár lidí, co používali kill. Všichni automaticky kill -9, fakt netuším proč.

[pavlix]

Protože je to rychlejší než pouštět kill, pak přes ps a grep kontrolovat, jak to dopadlo, a pak ve velké části případů stejně pouštět kill -9. Něco jiného by bylo, kdyby to celé uměl kill udělat sám.

[xkucf03]

Proč by to kontrolovali přes ps a grep? Stačí ten kill pouštět opakovaně a on ti řekne, že proces už neexistuje (šance, že by se mezi tím stejné ID přidělilo jinému procesu, je dostatečně malá, že s tím dokážu žít). A až tě to přestane bavit, tak akorát dopíšeš -9.

[pavlix]

Jo, to vlastně taky dělám, ani si to neuvědomuju. Ale když se mi párkrát stane, že se daný software neukončí, tak mě to přestane bavit a začnu ho střílet natvrdo.

[Chulda]

Jendnou mi tu službu spustilo znovu na jiném PIDu. Sundavalo se to nějakým obskurným příkazem z dílny DJBernsteina či co. Už si to moc nepamatuju, ale pamatuji si dobře, jak jsem málem rozmlátil klávesnici. Naštěstí to byl i posledni server s daemontools, se kterým sem se kdy setkal.

[Jendа]

Ale to se nejspíš stane i když to zabiješ KILLem.

[lertimir]

Ale když vím že je to konkrétní program tak ho mohu sundávat killall jméno a na jiný PID neuteče.

[xkucf03]

Spíš se bude spouštět znova a znova – akorát nebudeš muset opisovat čísla, ale výsledek je stejný. Procesy většinou spouští nějaký správce, který se jmenuje jinak a killall ho tudíž neukončí.

[trekker.dk]

Jo, v případě daemontools se ten správce jmenuje supervise. A pokud by někoho napadlo zabít nejdřív tohle, tak to jde, ale do pár vteřin se pustí jiný Ono je prostě lepší, když už člověk spravuje nějaký server, vědět, jak je udělaný.

[trekker.dk]

Rozmlátit klávesnici kvůli tomu, že nevíte, jakým způsobem jsou spouštěny služby na serveru, který spravujete? To je poměrně radikální řešení

[k3dAR]

radikalni by bylo rozmlatit ten server, klavesnice je sice v tom take nevine, ale aspon to jsou male ztraty

[trekker.dk]

Akorát tomu procesu nedáte šanci po sobě uklidit, takže když třeba používá sdílenou paměť nebo sysv semafory, tak to kill -9 uděláte několikrát a pak vás čeká dost nepříjemné překvapení. (A málokdo ví, že vůbec něco takového existuje, natož jak to řešit.)

[pavlix]

O jaké překvapení se jedná? Pokud systém nedokáže po procesech uklidit, hlásil bych to jako bug.

[Jendа]

Třeba tu sdílenou paměť používá ještě někdo jiný, ale očekává se, že ji uvolní ten proces, který jsi sestřelil.

[pavlix]

Jako by bylo zavolání kill -9 jedinou situací, kdy po sobě program nezvládne uklidit.

[trekker.dk]

Tak jedinou situací určitě ne, ale neuklidí po sobě se 100% pravděpodobností (narozdíl od chybových stavů, kdy se furt může spustit příslušný cleanup kód)

[pavlix]

Pravděpodobnost je v tomto případě jen věc nedostatku informací. Podle mého názoru je psaní aplikací a systémů tak, aby nastal po SIGKILL nebo jiné situaci, kdy aplikace nedostane čas se ukončit, větší problém než po SIGTERM chyba, a použití SIGKILL tu chybu jenom projeví.

[trekker.dk]

Ok, patche vítány. Pro začátek tohle dělá Apache.

[pavlix]

Pokud se problém objeví u projektů, kterým se aktivně věnuju nebo o tom alespoň uvažuju, tickety vítány. Těch projektů je docela dost, takže mi nikdo nemůže vyčítat, že se vedne N projektů nevěnuju N+prvnímu.

Co konkrétně používá apache httpd a za jakých okolností? Osobně se bez něj obejdu a nemyslím si, že se mu budu aktivně věnovat, ale zajímá mě to.

[trekker.dk]

ipcs na systému, kde běží Apache, to ukáže - SysV semafory a sdílenou paměť. K čemu konkrétně, to už jsem nezjišťoval. Každopádně přinejmenším tu sdílenou paměť vytvoří master proces a pracovní procesy ji jenom využívají. Když se master proces zabije SIGKILLem, neuvolní ji a zbytek už jsem psal - uděláte to párkrát a zapracuje system-wide limit na to, kolik sdílené paměti se může používat a toho Apache už nenastartujete, protože pokus o alokaci nového regionu selže.

Jasně, ty pracovní procesy by tu sdílenou paměť mohly uklidit, když jim zmizí rodič, ale neřekl bych, že jim to přísluší. Navíc běží pod normálním uživatelem, kdežto ta sdílená paměť patří rootovi, takže je otázka, jestli ji vůbec uklidit můžou.

Mám za to, že podobně to měl ještě donedávna postgres, kde ten region sdílené paměti mohl být docela velký.

[pavlix]

Jasně, ty pracovní procesy by tu sdílenou paměť mohly uklidit, když jim zmizí rodič, ale neřekl bych, že jim to přísluší.

Nepřísluší. Úklid po ukončených procesech zpravidla přísluší operačnímu systému, zvlášt pokud se jedná o omezené prostředky a zvlášť pokud je po sobě proces neumí uklidit při novém spuštění. Ale chápu, že svět není ideální, jen se snažím hledat chyby, tam kde se skutečně nacházejí.

[trekker.dk]

Úklid po ukončených procesech zpravidla přísluší operačnímu systému

Jo, to by určitě bylo hezké, ale podle všeho tohle rozhraní takhle navržené nebylo

[Lol Phirae]

Patche pro Apache jsou úplně marná věc. Na neschopnost téhle věci se korektně zrestartovat si pamatuju že si distribuční vývojáři stěžovali už někdy před 10+ lety a nikoho z upstreamu to absolutně nezajímalo. Zcela ve shodě s tím nikdo nebude řešit ani to, že je to rozbité, pokud někomu po mnoha minutách/desítkách minut dojde trpělivost a prostě to odstřelí natvrdo.

[Michal Kubeček]

Cože? Ten restart ještě pořád není opravený? Já ho tedy pořád restartuju ručně a místo logrotate používám cronolog, ale myslel jsem, že už to dávno není potřeba a že to dělám jen z pověrčivosti…

[Lol Phirae]

Ne, není. Hacky z sysvinit se šíří do systemd. Prostě to stále nefunguje.

[trekker.dk]

Jestli tohle není spíš tím, že systemd neumí potřebnou funkctionalitu, tj. po příkazu na ukočení procesu počkat a pak teprve poslat signál.

[pavlix]

Nebo tím, že to neumí nebo se rozhodl nevyužít autor toho konfiguráku. Tedy aspoň pokud máme srovnávat schopnosti systemd a initskriptů.

[Lol Phirae]

Mno ono to, že se ta věc není schopná ani korektně vypnout (jseš v podstatě omezen na experimentování s hodnotami toho timeoutu tak, aby to "většinou" proběhlo správně, jinak to stejně odstřelí systemd natvrdo) taky není nic moc.

P.S. Bude hůř... Po socket-based aktivaci apod. *píííp* všichni webmasteři toužili už desítky let.

[pavlix]

Mno ono to, že se ta věc není schopná ani korektně vypnout (jseš v podstatě omezen na experimentování s hodnotami toho timeoutu tak, aby to "většinou" proběhlo správně, jinak to stejně odstřelí systemd natvrdo) taky není nic moc.

To už je ovšem trochu jiné téma.

[trekker.dk]

Ještě jednou - co znamená korektně vypnout?

Ta stop akce odkázaná výše jasně vyžaduje graceful-stop, tj. dokončit rozpracované požadavky a pak teprve ukončit. Korektní vypnutí v takovém případě znamená počkat, než jsou všechny požadavky vyřízené. Tj. pokud vám vadí, že se Apache dlouho neukončuje, proč po něm chcete graceful-stop místo normálního stop?

Na té hodnotě s timeoutem není co experimentovat, je to čas, kdy už se rozhodnete dál nečekat a zbylé požadavky nevyřizovat. Dle mého názoru docela rozumný přístup - dát čas na vyřízení tomu, co jde, ostatní picnout.

[Lol Phirae]

Ještě jednou - co znamená korektně vypnout?

Prosímtě, korektně vypnout znamená to, že se to korektně vypne. Ne, že se to vypnout nepodaří s důsledky, které tady diskutujeme.

Na té hodnotě s timeoutem není co experimentovat, je to čas, kdy už se rozhodnete dál nečekat a zbylé požadavky nevyřizovat. Dle mého názoru docela rozumný přístup - dát čas na vyřízení tomu, co jde, ostatní picnout.

To je príma. A co ty semafory a sajrajt v paměti, co po tom zbydou? Tobě fakt přijde normální, že ta věc 20+ let má bug způsobující, že se v případě nějakého netriviálního vytížení není schopná ukončit ani po třeba 10 minutách a nikoho z vývojárů to nezajímá a nikdo to neřeší?

[trekker.dk]

Prosímtě, korektně vypnout znamená to, že se to korektně vypne.

Což taky udělá, když se tomu dá čas. Když si zadáte "dokonči stávající požadavky a pak se vypni", tak se nemůžete divit, když se Apache před vypnutím pokusí dokončit stávající požadavky. Dostáváte přesně to, o co jste si řekl. Jasně, dokončit požadavky může trvat dlouho, zejména když máte klienty na mobilním internetu, kterým vypadlo připojení. Jestli vám to vadí, neměl jste si o to říkat.

A co ty semafory a sajrajt v paměti, co po tom zbydou?

Nic - pokud Apache po tom timeoutu ukončíte normálně pomocí SIGTERM, přestane čekat na dokončení všeho a ukončí se během několika vteřin. Platí pro aktuální verze v Debianu Wheezy i Jessie.

Jasně, jestli systemd neumí nic jiného, než (1) udělej ExecStop, (2) pošli KillSignal a (3) po timeoutu pošli SIGKILL, tak je to dost na prd. Ale za to už Apache nemůže, protože metoda pro korektní vypnutí (graceful-stop, chvíli počkat, stop, po pár vteřinách je čistě vypnuto) existuje.

Tobě fakt přijde normální, že ta věc 20+ let má bug způsobující, že se v případě nějakého netriviálního vytížení není schopná ukončit ani po třeba 10 minutách a nikoho z vývojárů to nezajímá a nikdo to neřeší?

Viz výše. Pokud si řeknete o pomalé ukončení a ukončuje se to pomalu, není to bug.

[pavlix]

Jasně, jestli systemd neumí nic jiného, než (1) udělej ExecStop, (2) pošli KillSignal a (3) po timeoutu pošli SIGKILL, tak je to dost na prd.

Ve skutečnosti se podle dokumentace timeout aplikuje dvakrát. Jednou před KillSignal a jednou před SIGKILL. Jediné, co dělá ten trik se SIGCONT je, že se na (nastavitelný) timeout čeká dvakrát a nepošle se SIGTERM, tudíž se nedá službě šance na čisté okamžité ukončení. Další věc je, že člověk může v systemd pro ukončení spustit libovolnou sérii příkazů a kterýkoli z těch příkazů může být skriptem, tudíž v tomto případě systemd nepřináší žádné nové omezení.

[Lol Phirae]

člověk může v systemd pro ukončení spustit libovolnou sérii příkazů a kterýkoli z těch příkazů může být skriptem, tudíž v tomto případě systemd nepřináší žádné nové omezení.

No, hlavně nepřináší žádné zlepšení. Dobastlené skripty tak, aby to "většinou vyšlo", až máme z dob normálního initu.

[pavlix]

Nepřišel jsem flejmovat na téma systemd, od toho jsou jiní. Doplnil jsem pár subjektivně zajímavých a důležitých informací k tématu, protože trekker zjevně reagoval v kontextu ne zcela úplných a pravdivých informací. Buď to někomu pomůže, nebo ne.

[trekker.dk]

OK, v takovém případě systemd poskytuje všechno, co je potřeba. Místo toho triku by mělo stačit KillSignal=SIGTERM a použít oba timeouty. On ten odkazovaný service soubor je taky přes 2 roky starý, takže možná jenom nereflektuje to, co systemd tenkrát neuměl a dneska umí?

Každopádně to není tak důležité - ať už systemd umí nebo neumí cokoliv, nemá to vliv na to, jestli je v chování Apache je bug. A podle mě pořád platí, že když Apache dělá to, co se mu řeklo, že má udělat (což není nutně to uživatel chtěl, ale neuměl si o to říct), tak to bug není.

[pavlix]

On ten odkazovaný service soubor je taky přes 2 roky starý, takže možná jenom nereflektuje to, co systemd tenkrát neuměl a dneska umí?

Může to tak být. Nebo mohl být i před těmi dvěma lety kopírovaný od jinud nebo tvořený na základě starých znalostí. Jinak souhlasím s tím, že jediné řešení je skutečně Apache nechat udělat graceful-stop a namísto překvapení mu na to vymezit čas a následně udělat stop. Ale to už nezávisí na systemd versus initscripts.

[xkucf03]

Což taky udělá, když se tomu dá čas. Když si zadáte "dokonči stávající požadavky a pak se vypni", tak se nemůžete divit, když se Apache před vypnutím pokusí dokončit stávající požadavky. Dostáváte přesně to, o co jste si řekl. Jasně, dokončit požadavky může trvat dlouho, zejména když máte klienty na mobilním internetu, kterým vypadlo připojení. Jestli vám to vadí, neměl jste si o to říkat.

Ani to nemusí být mobilní klienti. Ten požadavek může být třeba stahování několikagygabajtového souboru a může trvat hodiny.

Je správné mít několik úrovní ukončování:

a) splň požadavky klientů a korektně se ukonči
b) kašli na klienty a korektně se ukonči
c) ukonči se teď hned (na to stačí kill -9)

[trekker.dk]

Co nefunguje na restartu? Nebo možná - co znamená korektně zrestartovat?

[Michal Kubeček]

U mne se to projevovalo tak, že po "apachectl restart" se u vytížených serverů občas (ne moc často) stalo, že server neběžel. IIRC byl problém v tom, že "stop" se za určitých okolností tvářil, že úspěšně proběhl, přestože některý proces ještě chvíli žil, takže "start" pak selhal.

[trekker.dk]

IIRC byl problém v tom, že "stop" se za určitých okolností tvářil, že úspěšně proběhl, přestože některý proces ještě chvíli žil, takže "start" pak selhal.

Nevím, jak kdysi, ale pro aktuální apachectl v Debianu restart neznamená stop a start. Ale jestli to tak dřív bylo, tak si dovedu představit, že k něčemu takovému mohlo dojít.

To mě netrápí - když chci Apache restartovat, tak mu pošlu SIGTERM a až to jde, runit už si ho nastartuje.

[pavlix]

Tak tohle zase na druhou stranu systemd (nebo jakýkoli jiný cgroups based service manager) řeší.

[pc2005]

Napadá někoho varianta s Magic SysRq?

[pavlix]

Jakože proč je sysrq lepší než vypínací tlačítko?

[Michal Kubeček]

Alt-SysRq-C určitě. :-)