[Résolu] umount 95% cpu, kill impossible

Support Debian
#1

Salut,

Tout est dans le titre, ce que j’ai fait:

Une partition sur mon disque usb pour cloner “/” puis dd if=/dev/hda7 of=/dev/sda2 bs=4096 conv=notrunc,noerror ensuite impossible de démonter, j’ai fini par l’éteindre comme un sauvage.

Conky affiche 100% de CPU donc je tape: [code]panda@linux:~$ top

top - 09:29:59 up 24 days, 13:31, 3 users, load average: 2.84, 2.59, 2.36
Tasks: 107 total, 3 running, 104 sleeping, 0 stopped, 0 zombie
Cpu(s): 4.0%us, 95.7%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.3%si, 0.0%st
Mem: 906408k total, 894228k used, 12180k free, 81568k buffers
Swap: 2650684k total, 70304k used, 2580380k free, 596920k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
10144 root 20 0 1972 656 548 R 93.5 0.1 543:47.53 umount
[/code]

Depuis je tente de l’arrêter mais rien n’y fait… :smt017

#2

euh j’ai pas tout a fait compris mai si c est pour un processus qui coince: kill -s 19 pid && renice -n 19 pid && kill -s 9 pid

après si sa marche pas je sai pas :unamused:

#3

linux:/home/panda# kill -s 19 10144 && renice -n 19 10144 && kill -s 9 10144 usage: renice priority [ [ -p ] pids ] [ [ -g ] pgrps ] [ [ -u ] users ]

J’ai mal interprété ta commande ?

#4

[quote=“Panda”]Salut,

Tout est dans le titre, ce que j’ai fait:

Une partition sur mon disque usb pour cloner “/” puis dd if=/dev/hda7 of=/dev/sda2 bs=4096 conv=notrunc,noerror ensuite impossible de démonter, j’ai fini par l’éteindre comme un sauvage.

Depuis je tente de l’arrêter mais rien n’y fait… :smt017[/quote]

Quand un répertoire ne veut pas se démonter avec umount, c’est qu’il est utilisé par un processus, tu peux voir quel(s) processus (PID) l’occupent en tapant :

fuser -v /chemin_du_rep/rep_à_démonter

et tuer le ou les PID que ça te retourne pour pouvoir faire ton umount

ou tu fais d’un coup :

fuser -k /chemin_du_rep/rep_à_démonter

pour tuer directement les processus qui occupent le répertoire et ensuite tu fais ton umount

#5

Tu as eu tort de tout arrêter, l’USB consomme beaucoup de ressources (il faut fabriquer les trames USB) et c’est lent, sans doute l’écriture sur le disque n’était pas fini, donc le umount attendait que le cache soit fini ce qui peut être très long (peut être ton USB s’est mis en USB1), en enlevant le disque tu as figé le bazar. Un kill ne changera rien car avant de répondre au signal, il est en attente d’une I/O matérielle.

#6

autrement tu peux essaye umount -l chemin

#7

+1 vu que dans ton cas tu étais en train de faire un dd (opération I/O) sur le disque monté en usb, tu ne pourra le démonter avec umount car c’est le processus dd qui utilise le point de montage, et que ce processus est surement dans l’état uninterruptible sleep ce qui signifie que même un kill -9 n’y pourra rien, pour forcer à tuer il faudrait tuer le processus parent (le terminal à partir duquel le dd a été lancé) mais le mieux c’est d’attendre que le dd soit fini c’est normal que ce soit long par le bus usb

#8

Démonter quoi, au juste ?
Les deux partitions étaient bien démontées avant de faire la copie (à la limite la partition source pouvait être montée en lecture seule) ?

#9

Tout est rentré dans l’ordre après un reboot, les deux partitions de mon “Pandex” sont intactes apparemment.

La prochaine fois que j’utiliserai la commande dd, je ferai plus attention… (en passant j’ai eu une “erreur d’entrée/sortie” en clonant ma partition racine, ça veut dire quoi ?)

Pour finir, j’ai juste flingué mon uptime de keke ! (panda.homelinux.net) :smt003

#10

sa veux dire que sa sens pas bon, après quoi exactement je sais pas, mai je suppose qu’un partie des donnée a été mal recopier.

#11

Je vais me porter sur backup-manager je pense, je n’ai jamais réussi à faire marcher bootcd…
En tout cas merci pour vos réponses :slightly_smiling: