halott processz

Linux-haladó

Üdv!

Van egy processz a "szerveremen", ami halott, de nem szűnik meg:
4788 ? D 0:00 [linux]

Ez egy uml-es gépnek a processze szeretne lenni. Már tőbb mint 15 órája benne van a ps ax kimenet-ben, nyitva tartja a root_fs-fájlt és idegesít. Kill -9 nem segít.
Mitől függ, h mikor tűnik el ill. hogyan lehet eltüntetni?

Köszönöm,
Csaba

  • 1170 megtekintés

( Zahy v | 2007. 03. 04., v – 00:38 )

Amikor egy processz meghal, szépen kitakarodik a rendszerből majdnem minden, ami hozzá tartozik. Megmarad pl. a processz táblabeli elem. A szülő processze kap egy "Death of a Child" megszakítást (SIGC(h)LD) - az pedig ekkor normális esetben kiad egy wait (vagy waitpid/wait3/wait4) rendszerhívást, és elveszi a meghalt processz státustát. Ekkor szűnik meg a processz véglegesen. Azaz max annyit lehet próbálni, hgy kill-lel Te küldj egy SIGCHLD-t a szülőnek.

( Elbandi v | 2007. 03. 04., v – 12:36 )

probald meg:
kill -CONT 4788

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Hi,
En is jartam mar egy parszor igy, es sehogy nem sikerult tole megszabadulni, de azt hittem a geppel van valami. Ezert is kivancsian varom a fejlemenyeket, hatha valaki megmondja mi lehet az oka, es mit lehet ilyenkor tenni (a rebooton kivul). Azert szerintem az durva, hogy elofordulhat olyan linux alatt, hogy egy futo processt nem lehet kiloni. Nem?

( uid_4672 | 2007. 03. 04., v – 13:00 )

van olyan amikor nem jó ha vannak zombie processzek, ilyenkor a signal(SIGCHLD, SIG_IGN) a program elején segít.
(pl. embededd rendszerben, limitált erőforrások esetén).

( bitumen | 2007. 03. 04., v – 14:56 )

"Azert szerintem az durva, hogy elofordulhat olyan linux alatt, hogy egy futo processt nem lehet kiloni. Nem?"

Fene tudja, elvégre ez a processz halott, dead. Remélem nem valami ügyes rootkit vagy hasonló...
Tripwire és chrootkit van a gépen, a tripwire kicsit elhanyagolt állapotban...

( apal v | 2007. 03. 04., v – 15:17 )

Ez nem zombi, hanem "uninterruptible sleep" statuszban levo" processz. Azt pedig nem lehet meggyilkolni csak ugy. A lenyege, hogy valamelyik kernelhivasbol nem te'rt vissza, vagyis pontosabban a kernelhivas olyan, ami nem megszakithato. Pelda (amit sokszor tapasztaltam): NFS. Ha lehal a szerver es egy processz veletlenul kozben nfs-en levo" fileokat/konyvtarakat baszkural (I/O, de egy sima `ls` is csinalja), akkor a processz D-be kerul. Ezt NFS-nel ugy lehet elkerulni, "soft,intr" mount-opciokkal mount-olod fel. Ha megsem ugy mountoldad fel, akkor csak a szerveroldali nfsd megbaszkuralasa segit, vagy kamu nfsd-k elinditasa localhoston (erre mar pontosan nem emlekszem, hogy hogy kellett csinalni, de valahogy meg lehet). De ha nem is az NFS miatt van ez a problema, akkor is sokat segithet egy `lsof` kimenet, kimondottan erre a processzre, es akkor ott meg lehet nezni hogy miket (diszk, particio, egyebek) fog a processz, hatha abbol kiderul valami okossa'g.

A.

( bitumen | 2007. 03. 04., v – 16:23 )

"Pontosan mi ez az /mnt/space/...? NFS?"
/mnt/space-re van bemountolva egy elég nagy partíció, amin a /home is van. /home-ban meg az uml user ~/ -je, és ő futtatja az uml-es gépeket.

Nfs-ez nincs sok köze az egésznek. (Meg van osztva az /mnt/space nfs-en keresztül, de ebben az esetben helyi fájlrendszerről van szó. )