Dotaz: Jak zabít mrtvé?

[Franta]

Část výpisu ps.

6990 ? D 0:08 /usr/lib/openoffice/program/soffice.bin -writer -splash-pipe=5

6752 ? D 0:00 bash

6770 ? D 0:00 mc

6424 ? Zs 0:00 [bash] <defunct>

6571 ? D 0:00 winecfg.exe

Dobrý den! Nemůže mi někdo poradit jak zlikvidovat či zabít tyto pěkné prográmky? Zombíci mi zas tak nevadí, ale vadí mi spuštěné wine, které nemůžu zabít (ani s -9). Nesmrtelné wine mi zabraňuje vstoupit do adresáře, kde je spuštěno.

Odpovědi

[1john2]

co zabiti jako root? nepomuze sudo kill -s9 xxxx? kazdopadne bych se byt vami, zajimal po pricine techto problemu a neresil jen nasledky..

[Franta]

Zabití jako root nepomůže. Ty mrchy to přežijou. Jinak další takové polofunkční programy na svém počítači umím vytvořit. (Vyjma zombíků)

[Jirka P]

Tak to máte smůlu. Mě se takhle občas kousne cdromka, což řeším tak, že uspím počítač a znova pustím.

Jinak Vám asi nepomůže nic jiného než reboot (nebo něco ekvivalentního).

[volca]

Kdyz ma proces stav D, vetsinou ceka na zarizeni (neprerusitelny spanek). Nepristupuji ty procesy nahodou na nejaky sitovy disk? Stavalo se mi to pri pristupu prez NFS, pokud pripojeni chybovalo.

Zabit ty procesy nejde, jelikoz spi. Nejdrive je potreba odstranit pricinu spanku - cekani na IO.

[Franta]

Přistupují na lokální, v průběhu odmountovaný disk. Další problém je, že wine mi zatuhlo pokud jsem přistupoval na windowsový disk. Pravděpodobně to působila nevyřešená práva.

[pushkin]

Zkus kill -SIGKILL xxxx

[fixinko]

proces v stave D a Z tym nezabijes...

[Radek Hladik]

Když už se tady o tom mluví, může mi někdo vysvětlit, proč není možné takový proces odstřelit? Pokud procesu posílám -9, tak už ho vlastně neposílám procesu, ale přímo kernelu. A ten normální proces ukončí i bez vědomí toho procesu.

Tak proč se to liší, když se proces zablokuje a čeká na nějaké I/O? Kernel přece ví, o které I/O se jedná (jinak by proces nemohl ve správnou chvíli vzbudit) a zároveň dané I/O provádí. Tak proč neukončí proces, neukončí I/O a kdyby to I/O nešlo, tak si ho zařadí někam do fronty "až tohle I/O skonční, tak výsledek ignoruj a co nejvíc po něm ukliď".

Když systém zrebootuju, tak se systém zombíků zvládne zbavit - minimálně mu nezabrání, aby dokončil vypínání - tak proč něco podobného neumí za běhu.

[Nikola Ciprich]

toto bude v novych kernelech reseno, psalo se o tom tusim v jednech z poslednich jadernych novin...

btw subjekt me fakt pobavil

[Bluebear]

Pokud procesu posílám -9, tak už ho vlastně neposílám procesu, ale přímo kernelu. A ten normální proces ukončí i bez vědomí toho procesu.

Jistě, to ale platí o každém signálu. Problém je v tom, že proces ve stavu D provádí nějakou kritickou operaci s hardwarem, kterou se kernel "bojí" násilně přerušit, aby nezpůsobil havárii ještě většího rozsahu.

Zombie proces (stav Z) je něco jiného; to je proces, který už je vlastně mrtvý, a existuje jen proto, že jeho rodič ještě nevzal na vědomí, že proces skončil, a nepřevzal si jeho výstupní hodnotu. Zombie se dá zbavit tím, že sestřelíš rodiče, případně několik vyšších rodičů, až se dostaneš k nějakému procesu (přinejhorším k initu), který akceptuje, že má pod sebou spoustu zombie procesů, a odstraní je.

Tedy aspoň doufám, že to tak je. Prosím nekamenujte mě, jestli jsem to popletl.

[stativ]

D neznamená, že je mrtvý, ale že je ve stavu uninterruptible sleep (nepřerušitelný spánek). V té době proces čekaké na nějaké IO tj. čte nebo ukládá data na disk apod. Do tohohle stavu se můžeš dostat odstraněním disku zrovna za běho IO, což se může stát i třeba pokud je připojen přes nestabilní síť.

Teoreticky by mohlo pomoci zařízení připojit zpět aby se operace dokončila. Slyšel jsem, že občas pomůže zabití parent procesu, ale to se mi zdá poněkud proti principu nepřerušitelného spánku. Možná by pomohlo odstranit modul ovládající dané zařízení (třeba by si toho pak proces všiml).

PS.: Jinak tohle je celkem logické chování, zabraňuje vzniku nekonzistence FS nebo ještě hůře vzniku kernel panic.

[Prom]

ze se ptam, da se nejak snadno zjistit, na co dotycny zombik ceka ? pripadam si trapne, ze musim svuj notebook pri trose instalacni prace restartovat i desetkrat... :( pravda, slax ma sve speciality, ale stejne.

[Jirka P]

On to neni zombik (to jen na okraj), ale zjistit se to da. ps -A -l (nebo ps -A -f, nevim presne) vypise ve sloupci wchan jmeno funkce ve ktere ceka, takze treba zjistite ze ceka na mutex, na skonceni jineho procesu, atd. Nezjistite teda na ktery mutex, to byste musel na to jit nejakym debuggerem nebo se rucne hrabat v pameti.

[Jooky (inactive)]

Presne tak.
D (neprerusitelne spanie) a Z (zombie) su dve rozdielne veci. Obydva su specificke stavy. Zombie uz z principu neni problem, pid existuje len preto ze parent si este neprebral navratovu hodnotu ale samotny process uz neexistuje. V pridade 'D' sa process moze znova prebrat a pokracovat v praci, preto moze drzat zamky, pamat, ... . V akuktualnej implementacii sa signal KILL zaradi na koniec signalovej fronty a caka nez sa preberie process.

[msk]

Obydva

Brutal :) ...

[Bluebear]

Možná by pomohlo odstranit modul ovládající dané zařízení (třeba by si toho pak proces všiml).

Mám zlé tušení, že kdo tohle udělá, ten do smrti veselý nebude

[stativ]

To neznamenená, že to nemůže fungovat.

[Bluebear]

Myslím, že bohužel ne...

Pokud je nějaký proces zaseklý v D stavu, interpretuju si to tak, čeká někde v kernelovém kódu, v modulu, kterého se to týká. Tzn. modul se používá, k jeho odstranění bude nutné použít rmmod --force a v tom případě se daný proces náhle octne uvnitř neplatné oblasti paměti v kernelu, což by mělo nedozírné následky, jak praví klasik

[stativ]

Zkoušet to nehodlám, ale řekl bych, že by to mohlo fungovat. I pokud by to vyvolalo kernel panic, tak by to bylo řešení.

[Bluebear]

Obával bych se poškození filesystému, zvlášť jestli se inkriminovaný modul současně používá i u jiných úložných zařízení.

Řekl bych, že milosrdnější by bylo provést normální shutdown, a pokud se ten shutdown nepodaří dokončit kvůli těm zaseknutým procesům, tak nouzová synchronizace přes Magic SysRq (pokud je k dispozici) a pak vypnout počítač natvrdo.

[ivan]

Nemas nahodou nfs disk, sw raid nebo namontovanej loopback device? Nekdy se nejaky vlakno v linux kernelu zasekne a nepokracuje dal. Dej echo "t" > /proc/sys/kernel/sysrq-trigger. Ono ti to vyvise vsechny tasky v kernelu vcetne stacktraces. Z toho poznas v jakym ovladaci tvuj proces visi. Zajimany je, ze samotna operace vypisu tasku casto umozni, ze se zaseknuty proces zase rozjede.

[Bluebear]

Kurník, teď mi něco došlo. Ty soubory, které jsou blokované v D stavu, jsou spuštěné z tvého lokálního disku? Jestli ano, tak doporučuju ze všeho nejdřív všechno zazálohovat - obávám se, že by to mohlo být způsobeno taky tím, že se s tebou loučí disk.

Potom bych zkusil mrknout do dmesg (příkaz dmesg), jestli kernel nevypisuje nějaká děsivá varování o chybách přístupu na disk - jestli ano, tak www.alza.cz nebo jiný e-shop dle vlastního výběru