Töten impossible

[Jan 'RedBully' Seiffert]

Marcus Werner wrote:
> Hi,
> 
> Nachtrag:
> Der ginzurichtende Delinquent heißt übrigens K3B und ist laut ps momentan 
> ununterbrechbar am I/O-machen.
Wenn du dir es in top/htop anschaust, ist er im "D" State?
Dann kannst du ihn nicht Toeten. AFAIK.
Signale (auch ein "KILL") werden an einen Prozess nicht geliefert, wenn
er im Kernel rumhaengt. Sowas passiert fuer gewoehnlich, wenn das
rumhantieren mit Devices "haengt".
Hinzu kommen noch verschiedene Signalsemantiken (SysV, POSIX, BSD), ob
ein Signal einen Systemcall unterbrechen darf oder nicht. Wenn man
ersteres da als Default einstellen wuerde, haeult ein haufen Developer
rum, da seine Software damit nicht rechnet, das ein Call fehlschlaegt,
und man auf EINTR testen muss, und es ggf. nochmal probieren muss (plus
SA_RESTART nach BSD was da reinspielt, da muss man aber dann sig_action
benutzen, nicht signal(3)). Alles sehr komplex...

Du kannst ja mal testen, ob das "auf den Parent schiessen" hilft.
Hmmm, Aber wenn ich mich richtig erinner, werden Elternlose Kinder an
Init gegeben und dann werden den Kindern auch nur Signale geschickt, das
der Parent gestorben ist.

> Hat wer ne Idee wie ich das Exorziert kriege?

Ihn mit Signalen totschiessen, alle die gross, boese und maechtig sind
(KILL, SEGV, ILL, BUS).
Wenn er dann irgendwann mal zufaellig aus dem Kernel kommt, wird er
schon sterben.

> Daran wird wohl das "nicht töten können" liegen. Aber mir erschließt sich 
> leider nicht die Lösung und Rebooten ist gegen meine Prinzipien.
> 
Ist aber die einfachere Loesung...
Hast du dabei viel CPU-Auslastung? Wenn nein, weitermachen...

Ich hab momentan fast das gleiche Problem. Mein K3B beginnt beim starten
irgendwie den SCSI-Bus zu scannen, loop dabei aber, und kommt nicht
vorwaerts. Natuerlich haengend im D-State.
Gluecklicherweise scheint er von Zeit zu Zeit aus dem Kernel zu kommen,
so das ein KILL dann nach 5 Min auch mal zugestellt wird...

> Grüsse,
> --
> Marcus
Gruss
	Jan

-- 
Treffpunkt fuer Gyrosfreunde