Dotaz: kill -9 nezabije proces

[tlamik]

v poslední době to vídávám poměrně často, kill -9 nezabije proces ... jeden případ je, když mám namapovaný nějaký disk přes cifs a na něm otevřené soubory pro zápis a widlí server někdo zrestartuje, tak mi nejde ani odmountit adresář a ani zabít ty procesy s devítkou. druhý případ řeším aktuálně, např. cat malého txt souboru (4kB) zabírá 99% CPU a nejde zabít. První případ asi nevyřeším, ale co druhý ? Tipuju na vadnou paměť. Je pravda, že před aktualizací jádra a OS si nepamatuju, že by to dělalo. Zkusím to ještě se starým jádrem ale štve mě proces co nejde zabít a musím trapně linux server resetovat .... nějaký tip ? Dík

Odpovědi

[Ash]

proces čekající na io opravdu (trapně) nejde zabít, umount můžete zkusit -f, což by mohlo pomoct, nebo někdy -l (lazy), i když s tím lazy nemám úplně nejlepší zkušenosti a nejsem si jist že by to pomohlo zabití těch procesů.

[Ash]

Jo a na ten 99% proces nefunguje nic? Ani STOP? A v syslogu v tu chvíli něco o io není?

[Heron]

Ten proces bude ve stavu Dead.

[Ash]

Ve stavu Dead asi nebude zabírat 99% CPU... ;)

[Michal2]

A tech 99% travi v userlandu nebo v jadru?

 

Kazdopadne ten prvni pripad je proces ve stavu neprerusitelneho cekani (to je mimochodem dobry argument pro kampan microsoftu misto tech volovin co tam maji ted. tuhle zalezitost ma windows naprosto nesrovnatelne lepe resenou). A to druhe bude zase sprajcnuti se v nejakem spinlocku toto jsem ovsem popravde jeste nevidel

 

[Heron]

99% času procesoru může trávit v IO Wait. (Čimž jinými slovy říkám totéž co kolega výše.)

[Ash]

Jistě, ale jak jsem řekl, nikoliv ve stavu Dead.

[houska]

druhý případ řeším aktuálně, např. cat malého txt souboru (4kB) zabírá 99% CPU a nejde zabít.

co zkusit strace co to dela?

[tlamik]

[root@node2 ~]# strace -p 10388
Process 10388 attached - interrupt to quit
 

a nic víc nebo mám pustit strace s dalšími parametry ? Tak nějak to pořád vidím na chybný HW, ale popravdě tohle je jiný stroj (už druhý) se stejnou chybou ve stejném kernelu.

[petr_p]

Nepravděpodobné, ale zkuste -f nebo -F.

Pokud ale strace nic nenašel, tak cat žádné nové služby systému nevolá. Takže se zacyklil.

Takže v jakém je stavu podle ps? Jestli S nebo D, tak zůstal viset v jádře. Pokud R, tak v uživatelském prostoru. Pak je dobré zkusit odtrasovat běh samotných instrukcí procesu. Třeba pustit gdb -p $(pidof cat) a podívat pomocí backtrace, v jaké funkci se točí.

[tlamik]

no tak momentálně mi tam nevisí ani cat ani grep , ale zjištění statusu databáze (nějaký proprietalní closedsource sw) a visí ve stavu R. kill -9 samozřejmě nic neudělá

[JF]

Pokud je vadna pamet, tak nema smysl vubec nic dalsiho resit! Pro jistotu to chce otestovat pamet treba pres noc. V pripade zajmu bych vyhrabal memcheck.

Kazdopadne jednim z dobrych testu pameti je kompilace kernelu nebo wine. Pokud se zkompiluji dobre, tak je pamet versinou v poradku.

[tlamik]

to vím, jde však o servery v clusteru a není možné si s nima moc hrát. Navíc třeba s takovým memtestem na značkových serverech nemívám moc dobrou zkušenost (sám nevím proč), na běžných PC mi běží memtest dobře, ale na některých servech detekuje buď neexistující chyby nebo jede moc zdechle. Do odbou serverů se přidávala paměť, aktualizoval jsem OS, vanillu kernel a oba mají podobné potíže.

[petr_p]

Pokud padá cat, tak je rozhodně lepší si hrát, než se těšit na skrytá vadná data (nebo vám stroje v clusteru o výsledku hlasují?).

[tlamik]

chápu,ale dělá to od doby, co jsem přidal paměť a aktualizoval OS a kernel. Nechce se mi věřit, že by byla vadná paměť na obou, tak to momentálně vidím nejvíc na kernel. Než testovat paměť celou noc, tak je pro mě jednodušší zkusit staré jádro. Ona se ta chyba projeví do dvou dnů spolehlivě... Navíc ty značkové RAMky made in HP byly drsně drahé a údajně testované :D

[Radovan Garabík]

Raz sme kupovali cluster 12 počítačov, a všetky mali zlú pamäť... (jedna séria). Dodávateľ nechcel reklamáciu uznať, trvalo to pol roka, než sme to vybavili (osobná návšteva u dodávateľa s počítačom, pustenie memtestu pred technikom). Problém bol v tom, že chyba sa prejavovala, len ak mal počítač zaplnené všetky 4 sloty. Pamäť samostatne bola dobrá.

[merlin111]

Nevím jestli to nebude mimo. Když jsem navyšoval paměť do svého PC, už nebyl k sehnání původní typ paměti (obě 400 Mhz, nová měla snad dokonce lepší CAS). Pro stabilní chod systému jsem musel mírně slevit z mého původního agresivnějšího nastavení časování.

[Max]

Také jsem to jednou zkoušel a s memtestem na server ee. Buď má problémy s ECC, nebo spíš s různými paměťovými featurkami, co servery mají :-/.
Takže na server používám testovací CD od HP postavené na linuxu :).
Zdar Max

[tlamik]

To testovaci CD od HP je volne ke stazeni ? je to klasika, nabootuje se a testuje ? jde to udelat pres iLO, aniz bych to CD dal fyzicky do mechaniky ?

[JF]

Prave naopak. Pokud je vadna pamet, tak dochazi k naprosto nekontrolovatelnym havariim a muze dojit i ke zdrate dat s disku.

[Atom321]

Chová se to, jako by u cifs mountu byl použitý option "hard", tj. při nedostupnosti serveru zůstane zablokovaný. Zkuste použít mount option "soft", viz manuál:

http://www.samba.org/samba/docs/man/manpages/mount.cifs.8.html

Ve druhém případě cat zřejmě uvízl na nějakém cyklu v jádře. (Kdyby cyklil v userspace, šel by zabít.) Může to být (jak píšete) chyba paměti, disku, slabý zdroj (projevuje se jako náhodné HW chyby všeho možného) nebo i chyba v kernelu. Z jakého filesystému berete ten "malý txt soubor"? Jakou verzi jádra máte? Je dost volné paměti? Používáte swap?

Jako dočasnou pomoc mu můžete snížit prioritu (renice), nebo ho zkusit pozastavit (kill -SIGSTOP). Bude tam viset dál, ale nebude tolik blokovat procesor.

[tlamik]

tak se starším jádrem mi to sice nedělá, ale zase se mi objevuje kernel panic. Zkoušel jsem přes noc memtest a bez chyby. Tak jsem celkem v koncích

 

[petr_p]

Zkoušel jste 2.6.30.6 nebo 2.6.31? Jsou tam opravené nějaké souběhy při práci s vlákny.

[tlamik]

as far as I know : server bezel bez potizi na 2.6.24.3, pak jsem do nej pridal RAM, sitovou kartu a dva SAS disky. Nejsem si jist, jestli to zlobi presne od te doby, skoro bych rekl, ze ne. Moje posledni akce byla yum update a pak build 2.6.31 vanilly + drbd. Pak zacly problemy s procesy, co nesly zabit. V puvodnim kernelu 2.6.24.3 se sice tyto procesy nevyskytuji, nicmene se mi objevuje kernel panic, pravda ne tak casto jako ty nezabijitelne procesy ve 2.6.31