it-swarm.com.de

Linux: Welcher Prozess führt beim Umount zu "Gerät beschäftigt"?

Linux: Welcher Prozess führt beim Umount zu "Gerät beschäftigt"?

68
flybywire

Schauen Sie sich den Befehl lsof an (liste geöffnete Dateien) - er kann Ihnen sagen, welche Prozesse welche geöffnet haben. Manchmal ist es schwierig, aber oft kann etwas so einfaches wie Sudo lsof | grep (your device name here) es für Sie tun.

95
MarkusQ

Nur für den Fall, dass Sie manchmal umount vom Terminal aus anrufen und Ihr aktuelles Verzeichnis zum angehängten Dateisystem gehört.

41
alvatar

Sie sollten den Befehl fuser verwenden.

Z.B. fuser /dev/cdrom gibt die PID (s) des Prozesses mit /dev/cdrom zurück.

Wenn Sie versuchen, die Bereitstellung aufzuheben, können Sie diesen Prozess mit dem Schalter -k beenden (siehe man fuser).

21
Ben

Suchen Sie nach Geräten mit offener Schleife, die einer Datei im Dateisystem mit "losetup -a" zugeordnet sind. Sie werden weder mit lsof noch mit der Fixiereinheit angezeigt.

17
Jay

Überprüfen Sie auch /etc/exports. Wenn Sie Pfade innerhalb des Mountpunkts über NFS exportieren, wird dieser Fehler ausgegeben, wenn Sie versuchen, die Bereitstellung aufzuheben. In fuser oder lsof wird nichts angezeigt.

15
Malvineous
lsof +f -- /mountpoint

(als Liste der Prozesse, die Dateien auf dem Mount verwenden, die am/Mountpoint eingehängt sind. Besonders nützlich, um herauszufinden, welche Prozesse einen eingebauten USB-Stick oder eine CD/DVD verwenden.

8
mas

lsof und fuser sind in der Tat zwei Möglichkeiten, um den Prozess zu finden, mit dem eine bestimmte Datei geöffnet bleibt. Wenn Sie möchten, dass umount erfolgreich ist, sollten Sie die Optionen -f und -l untersuchen.

7
Anonymous

Genau aus diesem Grund gibt es "fuser -m/mount/point".

Übrigens, ich glaube nicht, dass "fixer" oder "lsof" anzeigt, wann eine Ressource vom Kernelmodul gehalten wird, obwohl ich dieses Problem normalerweise nicht habe.

4
Carter Galle

lsof und fuser gaben mir auch nichts.

Nachdem ich alle möglichen Verzeichnisse in .old umbenannt und das System jedes Mal neu gestartet hatte, nachdem ich Änderungen vorgenommen hatte, fand ich ein bestimmtes Verzeichnis (in Bezug auf Postfix), das verantwortlich war.

Es stellte sich heraus, dass ich einmal einen Symlink von/var/spool/postfix zu/disk2/pers/mail/postfix/varspool erstellt hatte, um das Plattenschreiben auf einem SDCARD-basierten Root-Dateisystem (Sheeva Plug) zu minimieren.

Mit diesem symbolischen Link konnte ich auch nach dem Stoppen der Postfix- und Dovecot-Dienste (sowohl ps aux als auch netstat -tuanp zeigten nichts im Zusammenhang) die Bereitstellung von/disk2/pers aufheben.

Nachdem ich den Symlink entfernt und die Postfix- und Dovecot-Konfigurationsdateien aktualisiert hatte, um direkt auf die neuen Verzeichnisse in/disk2/pers/zu verweisen, konnte ich die Dienste erfolgreich beenden und das Verzeichnis aufheben.

Nächstes Mal werde ich die Ausgabe von:

ls -lR /var | grep ^l | grep disk2

Der obige Befehl listet alle symbolischen Links in einer Verzeichnisstruktur (hier beginnend mit/var) rekursiv auf und filtert die Namen heraus, die auf einen bestimmten Ziel-Mount-Punkt (hier disk2) zeigen.

2
captcha

Wenn Sie Ihr Gerät nach dem Stoppen aller Dienste und Prozesse mit geöffneten Dateien immer noch nicht aushängen oder erneut bereitstellen können, ist möglicherweise eine Auslagerungsdatei oder eine Auslagerungspartition vorhanden, die das Gerät beschäftigt. Dies wird nicht mit fuser oder lsof angezeigt. Deaktivieren Sie das Tauschen mit:

Sudo swapoff -a

Sie können dies vorher überprüfen und eine Zusammenfassung aller Swap-Partitionen oder Swap-Dateien anzeigen mit:

swapon -s

oder:

cat /proc/swaps

Als Alternative zur Verwendung des Befehls Sudo swapoff -a können Sie möglicherweise auch den Swap deaktivieren, indem Sie einen Dienst oder systemd unit anhalten. Zum Beispiel:

Sudo systemctl stop dphys-swapfile

oder:

Sudo systemctl stop var-swap.swap

In meinem Fall war das Deaktivieren des Swap-Vorgangs erforderlich. Außerdem wurden alle Dienste und Prozesse angehalten, deren Dateien zum Schreiben geöffnet waren, sodass ich meine Root-Partition als schreibgeschützt neu einhängen konnte, um fsck auf meiner Root-Partition ohne Neustart auszuführen. Dies war auf einem Raspberry Pi mit Raspbian Jessie notwendig. 

1
Simon Gould

Dateien öffnen

Prozesse mit offenen Dateien sind die üblichen Schuldigen. Zeigen Sie sie an:

lsof +f -- <mountpoint or device>

Die Verwendung von /dev/<device> anstelle von /mountpoint bietet den Vorteil, dass ein Mountpoint nach einem umount -l verschwindet oder durch ein überlagertes Mount verborgen wird.

fuser kann auch verwendet werden, aber meiner Meinung nach hat lsof eine nützlichere Ausgabe. fuser ist jedoch nützlich, wenn es darum geht, die Prozesse zu beenden, die zu Ihren Dramen führen, damit Sie Ihr Leben weiterführen können.

Dateien auf <mountpoint> auflisten (siehe oben):

fuser -vmM <mountpoint>

Beenden Sie interaktiv nur Prozesse, deren Dateien zum Schreiben geöffnet sind:

fuser -vmMkiw <mountpoint>

Nach dem Remounting von Read-Only (mount -o remount,ro <mountpoint>) ist es sicher (r), alle verbleibenden Prozesse abzubrechen:

fuser -vmMk <mountpoint>

Einhängepunkte

Der Täter kann der Kern selbst sein. Ein anderes Dateisystem, das auf dem Dateisystem angehängt ist, das Sie umount versuchen, verursacht Trauer. Überprüfen Sie mit:

mount | grep <mountpoint>/

Überprüfen Sie für Loopback-Mounts auch die Ausgabe von:

losetup -la

Anonyme Inodes (Linux)

Anonyme Inodes können erstellt werden durch:

  • Temporäre Dateien (open mit O_TMPFILE)
  • inotify Uhren
  • [eventfd]
  • [eventpoll]
  • [Timerfd]

Dies ist der schwerste Pokemon-Typ und erscheint in der Spalte lsof der Variable TYPE als a_inode (der in der Manpage lsof nicht dokumentiert ist).

Sie werden nicht in lsof +f -- /dev/<device> angezeigt, daher müssen Sie Folgendes tun:

lsof | grep a_inode

Informationen zum Beenden von Prozessen mit anonymen Inodes finden Sie unter: Aktuelle Inotify-Überwachungen auflisten (Pfadname, PID) .

1
Tom Hale

Dateisysteme, die auf dem Dateisystem gemountet werden, das Sie aufzuheben versuchen, können zusätzlich zu den verwendeten Dateien den target is busy-Fehler verursachen. (Zum Beispiel, wenn Sie mount -o bind /dev /mnt/yourmount/dev verwenden, um dort chroot zu verwenden.)

Um herauszufinden, welche Dateisysteme im Dateisystem eingehängt sind, führen Sie Folgendes aus:

mount | grep '/mnt/yourmount'

Um herauszufinden, welche Dateien verwendet werden, die Ratschläge, die bereits von anderen vorgeschlagen wurden:

lsof | grep '/mnt/yourmount'

0
Slobodan Pejic