# mount-prozess lässt sich nicht "killen"

## windoof

Hallo, ich folgendes Problem: ich versuche eine CD mit mp3-Files einzubinden. Entweder ist die CD defekt oder irgendetwas anderes verhindert den Erfolg. Jedenfalls versucht mount die CD zu mounten und hängt sich dabei auf. Jetzt kann ich werder die CD auswerfen noch mit kill den mount-prozess beenden. nur ein Reboot hilft. Frage: gibt es was "schärferes" als kill? So wie bei den init-modulen die option "zap"?

----------

## Squiddle

 *windoof wrote:*   

> Hallo, ich folgendes Problem: ich versuche eine CD mit mp3-Files einzubinden. Entweder ist die CD defekt oder irgendetwas anderes verhindert den Erfolg. Jedenfalls versucht mount die CD zu mounten und hängt sich dabei auf. Jetzt kann ich werder die CD auswerfen noch mit kill den mount-prozess beenden. nur ein Reboot hilft. Frage: gibt es was "schärferes" als kill? So wie bei den init-modulen die option "zap"?

 

zap is ganz schwach. es sagt ja nur ignorier alles was du weißt, der service IST NICHT gestartet  :Smile: 

kill sendet standardmäßig das TERM signal

du kannst mit 

```
kill -s KILL pid
```

das KILL Signal senden, von dem wird programmiertechnisch erwartet, dass es nicht ignoriert werden darf.

man kill hätte dir das aber auch gesagt...

----------

## Anarcho

oder einfacherer kill -9 pid

Das KILL signal kann nicht abgefangen werden. Soweit ich weiss greift das direkt beim Kernel und der beendet dann den prozess, so das sich dieser garnicht wehren kann.

----------

## windoof

wenn die Beschreibung der man-page geholfen hätte, hätte ich nicht geposted. Leiderbringt eben kill -9 pid gar nix. Habe die unterschiedlichsten signale probiert, aber der mount-prozess bleibt hartnäckig bestehen und meine cd im laufwerk. Hilft wirklich nur der reboot?

----------

## chrib

Schonmal probiert den Vaterprozess, also die Shell in der Du den Mountbefehl ausgeführt hast abzuschiessen?

Ansonsten kannst Du Dir  das mal durchlesen.

HTH

Christian

----------

## Genone

bringt alles nichts, der mount Prozess hängt irgendwo im Kernelspace, da würde dir auch ein SIGARMAGEDDON nicht weiterhelfen.

----------

## c07

Zufällig hab ich eine Methode gefunden, so was Ähnliches zu reproduzieren (Ausgaben gekürzt):

```
~ # dd if=/dev/zero of=/var/tmp/pkg bs=128M count=1

~ # losetup /dev/loop0 /var/tmp/pkg

~ # mkfs.reiserfs -qb512 /dev/loop0

~ # mount /dev/loop0 /mnt/tmp

~ # cp -a /var/db/pkg/* /mnt/tmp

Segmentation fault

~ # df /mnt/tmp

Filesystem           1K-blocks      Used Available Use% Mounted on

/dev/loop0              131040      3864    127176   3% /mnt/tmp

~ # umount /mnt/tmp
```

Dann hängt er und lässt sich auch nicht mehr von kill beeindrucken. Wenn ich die Shell abschieß, wird der umount-Prozess an init vererbt. Das System bleibt prinzipiell ziemlich funktionsfähig, aber es lässt sich nicht mehr runterfahren. Beim Versuch hängt das shutdown ebenso wie das umount, bevor es irgendwas gemacht hat (außer die Meldung auszugeben). Der Hänger ist wohl einfach im Kernel selbst, deshalb hilft da kein kill mehr.

Falls sich wer für die Details intressiert: /var ist bei mir ext2 mit 1024er-Blockgröße; Kernel ist gentoo-dev-sources-2.6.9-r9. Sonst hab ich kein Reiser auf meinem System. Es stürzt offenbar nur mit 512er-Blocks ab (jedenfalls nicht mit 1024ern) und schreibt noch das ins Syslog:

 *Quote:*   

> [kernel] ReiserFS: loop0: warning: vs-8115: get_num_ver: not directory item
> 
> [kernel] ReiserFS: loop0: warning: vs-8111: get_num_ver: split_item_position is out of boundary

 

----------

## amne

 *Genone wrote:*   

> bringt alles nichts, der mount Prozess hängt irgendwo im Kernelspace, da würde dir auch ein SIGARMAGEDDON nicht weiterhelfen.

 

Cool, das kenn ich noch gar nicht, was ist denn der numerische Parameter dafür? kill -666?

----------

## Shadows

Hi zusammen

Das selbe Prob hatte ich auch schon öfters, allerdings auch schon bei "normalen" umount-Versuchen - wenn auch sehr selten.

Abschießen kann man den Prozess tatsächlich nicht, was aller Wahrscheinlichkeit daran liegt, dass, wie Genone schon richtig angedeutet hat, das Ganze im Kernelspace hängt. Generell kann man Prozesse, welche auf I/O-Requests warten, nicht abschießen, bzw. genau genommen kann man sie schon abschießen, aber sie werden erst dann wirklich beendet, wenn der I/O-Request, bei welchem der Prozess gerade hängt, abgeschlossen ist (das eben beschriebene habe ich aus eigenen Beobachtungen geschlossen - falls ich da was falsches geschrieben habe, lasse ich mich gerne korrigieren).

Das nervige daran ist natürlich, dass der hängende mount-Prozess 100% CPU-Zeit frisst, was aber bei neueren Versionen von top dann auch richtig als wa / hi / si angezeigt wird (weiß nicht mehr genau, welches davon). Allerdings hat der umount-Prozess sich bei mir bisher jedes mal automatisch beendet, meist nach ein paar Minuten. Kannst also einfach mal ausprobieren ein paar Minuten zu warten (kann durchaus schon mal 15 Minuten sein). Ist natürlich keine tolle Lösung, aber immerhin kein Neustart vonnöten - falls das auch beim mount-Versuch klappt...

Greetz

Shad

----------

