• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Mount USB-Device: Aufwecken unbeteiligter HDDs vermeiden

Christina

Moderator
Teammitglied
Hi,
seit openSUSE Leap 15.2 habe ich das seltsame Problem, dass beim Mounten oder Unmounten eines USB-Thumbdrive durch das DE gleichzeitig die unter /dev/sdb befindliche HDD aus dem "STANDBY mode" aufgeweckt wird,
dann minutenlang im "ACTIVE or IDLE mode" bleibt und wieder in den "STANDBY mode" wechselt.
Beim Auswerfen per Filemanager "Thunar" oder "Nautilus" passiert genau das Selbe nochmal, was ich störend finde.

Beim Mounten von Hand z.B. per
Code:
udisksctl mount --block-device /dev/sdc1
udisksctl unmount --block-device /dev/sdc1
oder als root (nur falls vorher per udisksctl gemountet wurde):
Code:
umount /dev/sdc1
wird die HDD ebenfalls immer aufgeweckt.
Aber:
Code:
mount /dev/sdc1 /mnt
als root lässt die HDD auf /dev/sdb dagegen in ihrem STANDBY mode.

Die Suche im www ergibt z.B. diese Treffer hier, in denen das Problem wohl auch genau lokalisiert werden kann.
 Don't wake sleeping HDDs each time an unrelated disk is mounted/unmounted #611
 Ubuntu 18.04 mount/umount causes drives resume from standby state
Das hier habe ich ausprobiert und den Logger eingebaut. Beim Mounten findet sich dort aber kein Eintrag!
Das heißt vermutlich, dass dumpe2fs gar nicht involviert ist.
 Why is dumpe2fs called without user interaction?
Weiter steht dann nur noch der Hinweis auf udisks2. Und da weiß ich leider nicht weiter.

Der PC hier ist schon älter und hatte unter openSUSE Leap 15.1 definitiv nie dieses Problem;
egal ob mit USB-Pendrive, USB-CDROM (=extern), SATA-CDROM (=intern) oder USB-HDD.
Dieses Fehlverhalten trat erstmals mit dem Online-Upgrade auf Leap 15.2 auf. Per Upgrade läuft jetzt Leap 15.3.

Ob es dafür einen Workaround gibt, kann ich nicht beurteilen. Vielleicht hilft eine Neuinstallation (wäre halt aufwendig).
Hätte jemand von Euch Lust und Zeit, mit mir zusammen dieses unerwünschte Aufwecken der HDD zu enträtseln?

lg Christina
 

josef-wien

Ultimate Guru
Ich kann Dir bei der Aufklärung dieses bug von udisks2 nicht helfen. Du mußt zuerst die aktuelle Version 2.9.4 installieren (z. B. von http://download.opensuse.org/repositories/home:/TruckerZer0/15.3/) und schauen, ob der Fehler noch existiert. Im OSS-Repo von 15.3 sehe ich die Version 2.8.1, damit macht eine Fehlersuche keinen Sinn.
 
OP
Christina

Christina

Moderator
Teammitglied
Bei meinem PC (läuft mit GNOME) hatte ich das gleiche Phänomen mit dem Upgrade von Leap 15.1 auf 15.2.
Leider ist der beim Online-Upgrade auf Leap 15.3 abgeschmiert, sodass ich Neuinstallation mit Leap 15.3 machen musste.
Seitdem wacht meine HDD (auch unter /dev/sdb) nicht mehr auf, wenn ich ein USB-Laufwerk einstecke und Gnome es mountet & unmountet.
Ich könnte also beide PCs (Leap 15.3) vergleichen. Beim dem von meiner Freundin läuft aber XFCE als DE.
Hättest du vielleicht eine Idee, was ich per ssh nachsehen kann?
 

josef-wien

Ultimate Guru
Nachdem es nach der Neuinstallation funktioniert, scheint es nicht an udisks2 selbst zu liegen.

Das Ein- und Aushängen wird von der jeweiligen grafischen Oberfläche veranlaßt. Da ist theoretisch eine Konfigurations-Altlast von udisks2, GDBus oder der grafischen Oberfläche selbst denkbar. Zu udisks2 kannst Du den Stand der diesen Begriff enthaltenden Pakete und die darin enthaltenen Konfigurationsdateien sowie nach udisksctl monitor mit nachfolgendem Anschließen des Mediums die Ausgaben vergleichen (viel verspreche ich mir von allem nicht). Zum Rest kann ich nichts sagen.
 
A

Anonymous

Gast
Rein Interessehalber sind bei Suse die gleichen Zusätze[Pakete] implementiert wie bei Debian?
https://packages.debian.org/de/sid/udisks2

Ich finde im Moment keinen Bezug dazu, :???: bei Suse.

https://software.opensuse.org/package/udisks2
https://build.opensuse.org/package/show/Base%3ASystem/udisks2
 
OP
Christina

Christina

Moderator
Teammitglied
josef-wien schrieb:
udisksctl monitor […]
(viel verspreche ich mir von allem nicht)
Wenn XFCE das USB-Flashdrive mountet und 10 Minuten später die SATA-HDD zurück in den "STANDBY mode" wechselt,
weckt als root ein
Code:
umount /dev/sdh1
die HDD wieder auf, aber udisksctl monitor liefert in diesem Moment lediglich:
Code:
15:16:12.528: /org/freedesktop/UDisks2/block_devices/sdh1: org.freedesktop.UDisks2.Filesystem: Properties Changed
  MountPoints:          
15:16:16.225: /org/freedesktop/UDisks2/block_devices/sdh1: org.freedesktop.UDisks2.Block: Properties Changed
  UserspaceMountOptions:
Gibt es eine Möglichkeit, hier noch tiefer nachzusehen, was da genau passiert? – freedesktop.org?
 
A

Anonymous

Gast
montagne schrieb:
Rein Interessehalber sind bei Suse die gleichen Zusätze[Pakete] implementiert wie bei Debian?
https://packages.debian.org/de/sid/udisks2

Christina schrieb:
..Gibt es eine Möglichkeit, hier noch tiefer nachzusehen, was da genau passiert? – freedesktop.org?
...anders rum gefragt :???:
Ist das Paket bei Suse dabei ?

Code:
dep: libudisks2-0 (>= 2.9.0)
    GObject-basierte Bibliothek für den Zugriff auf udisks
 

josef-wien

Ultimate Guru
Code:
dbus-monitor --system
Aber frage mich nichts dazu, ich habe das Ding noch nie verwendet.

Deine beiden Zeilen protokollieren die Information an udisks2, daß etwas mit dem Medium passiert ist. Da udisks2 sonst nichts protokolliert, gehe ich davon aus, daß das Aufwecken der anderen Medien nicht von udisks2 ausgelöst wird.
 
Christina schrieb:
....
Gibt es eine Möglichkeit, hier noch tiefer nachzusehen, was da genau passiert? – freedesktop.org?


Was sich da tut:

# umount /dev/sdh1

umount sendet die Information an den kernel
Der kernel sendet einen uevent zurück in den userspace
Sieht ca. so aus:
Code:
 Kernelspace        |         Userspace
                    |
kernel (uevent) --> | -> udevd --------> udiskd -----> | DBUS |----> X Applikation
                    |   [udev rules]

udevd empfängt über den uevent die Infos und wertet entsprechend die udev_rules aus.
Handelt es sich um ein Blockdevice (könnte ja auch ein Netzwerkkabel sein)
sendet udevd die Info weiter an den udiskd.
udiskd hängt an der anderen Seite am D-Bus.
Der D-Bus ist eine bidirektionale Kommunikationsschnittstelle zwischen der
unteren Ebene hinauf zum Desktop, also den Applikationen unter X.
udiskd übersetzt die Info vom udevd in eine URI.
z.B. /org/freedesktop/UDisks2/block_devices/sdh1 + Info was passiert ist,
in dem Fall umount. Alle Applikationen, die irgendwas mit Blockdevices zu tun haben,
empfangen diese URI und können entsprechend reagieren.
Das ganze funktioniert natürlich auch in die andere Richtung.

In deinem Fall sendet der udiskd zwei Infos über den D-Bus.
1. Etwas am Filesystem hat sich geändert
2. Der Zustand des Blockdevices hat sich geändert.

Warum 1?
Weil der mountpoint auf deiner SATA-HDD liegt und sich damit tatsächlich etwas
am Filesystem auf dieser HD ändert. Genau das wird die Platte aufwecken.
Diese Info wird aber nicht unbedingt gebraucht, ist eher eine Fleißaufgabe.

Der kernel ist schuldlos.
udevd könnte eventuell auf Grund einer rule diese Info an den udiskd senden, oder
udiskd macht das. In beiden Fällen sollte das konfigurierbar sein.
Nun weißt du, wo du nachsehen mußt.

Gruß
Gräfin Klara
 
A

Anonymous

Gast
Nur nicht helfen lassen *kopfschüttel :???: :zensur: :schockiert:

..und Tschüss
 
OP
Christina

Christina

Moderator
Teammitglied
josef-wien schrieb:
Deine beiden Zeilen protokollieren die Information an udisks2, daß etwas mit dem Medium passiert ist. Da udisks2 sonst nichts protokolliert, gehe ich davon aus, daß das Aufwecken der anderen Medien nicht von udisks2 ausgelöst wird.
Die Ausgabe von dbus-monitor --system ist zwar schön ausführlich, bringt aber ebenfalls keinen Hinweis auf die SATA-HDD.
Wie du schon vermutet hast, liegt es demnach nicht an udisks2.
Gräfin Klara schrieb:
"Wenn der mountpoint auf deiner SATA-HDD liegt ..."
Der Mountpoint der USB-Drives liegt unter /run/media/{user}/{FS-Label}
Die ext4-Partition der 1TB-HDD unter /dev/sdb1 wird nach /home/public gemountet. (Ich habe das so eingerichtet.)
Gräfin Klara schrieb:
udevd könnte eventuell auf Grund einer rule diese Info an den udiskd senden, oder
udiskd macht das. In beiden Fällen sollte das konfigurierbar sein.
Nun weißt du, wo du nachsehen mußt.
Vielen Dank für deine Erklärungen zu Kernelspace & Userspace, aber beim "Nachsehen" müsstest du mir schon etwas helfen. ;)
Wenn die HDD sich bereits dreht (ACTIVE or IDLE mode) und das USB-Thumbdrive ausgeworfen wird, hört man deutlich das "Pling" im PC, weil der Schreib-/Lesekopf der HDD aus seiner Parkposition geholt wird. Das passiert irgendetwas…

Für mich steht der (private) Lerneffekt im Vordergrund, für meine Freundin muss Linux sauber laufen. Und das tut es ja. Der Fehler nervt nur. Eine Neuinstallation ist 4 Mal aufwendiger, bis wirklich alles wieder läuft. Das habe ich bei meinem PC ja gesehen. Wenn schon neu installieren, dann würden wir beide das auf Juni 2022 mit Leap 15.4 verschieben.

LG Christina
 

josef-wien

Ultimate Guru
Du kannst noch als root
Code:
iotop -oqqqn 10
versuchen. Nach dem Start von iotop hast Du 10 Sekunden Zeit, das Ein- oder Aushängen durchzuführen. Die Frist kannst Du natürlich anpassen und die Ausgabe in eine Datei umleiten.
 
OP
Christina

Christina

Moderator
Teammitglied
Als Ausgabe kommt (bei: udisksctl power-off -b /dev/sdh1)
Code:
$ iotop -oqqqn 10
 2073 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.60 % udisksd
17003 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.25 % [kworker/1:0-mm_percpu_wq]
  976 be/3 root        0.00 B/s   54.42 K/s  0.00 %  0.14 % [jbd2/sda3-8]
 7621 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.14 % [kworker/3:1-mm_percpu_wq]
  438 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.10 % systemd-udevd
 3510 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.09 % [kworker/2:1-mm_percpu_wq]
 7600 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.08 % [kworker/3:5-events_freezable_power_]
 7283 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.07 % [kworker/3:2-events_freezable_power_]
 7656 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.02 % [kworker/0:2-events]
 8454 be/4 nscd        0.00 B/s    3.89 K/s  0.00 %  0.00 % nscd
 1120 be/4 root        0.00 B/s   11.66 K/s  0.00 %  0.00 % rsyslogd -n -iNONE [rs:main Q:Reg]
 1677 be/4 root        0.00 B/s    3.89 K/s  0.00 %  0.00 % X :0 -seat seat0 -auth /run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
  348 be/3 root        0.00 B/s   15.51 K/s  0.00 %  0.13 % [jbd2/sda1-8]
17003 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.12 % [kworker/1:0-events]
31567 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.08 % [kworker/2:2-events_freezable_power_]
 3510 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.05 % [kworker/2:1-events_freezable_power_]
 7656 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.03 % [kworker/0:2-events]
 1677 be/4 root        0.00 B/s    3.88 K/s  0.00 %  0.00 % X :0 -seat seat0 -auth /run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
17491 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.24 % [kworker/2:4-events]
17490 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.19 % [kworker/2:3-events_freezable_power_]
31567 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.15 % [kworker/2:2-events_freezable_power_]
17003 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.14 % [kworker/1:0-mm_percpu_wq]
 3510 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.10 % [kworker/2:1-events_freezable_power_]
17489 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.05 % [kworker/2:0-events_freezable_power_]
 7656 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.03 % [kworker/0:2-events]
  976 be/3 root        0.00 B/s   19.42 K/s  0.00 %  0.13 % [jbd2/sda3-8]
17490 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.21 % [kworker/2:3-mm_percpu_wq]
31567 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.17 % [kworker/2:2-events_freezable_power_]
  348 be/3 root        0.00 B/s    0.00 B/s  0.00 %  0.15 % [jbd2/sda1-8]
17003 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.14 % [kworker/1:0-mm_percpu_wq]
 3510 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.13 % [kworker/2:1-events_freezable_power_]
17489 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.08 % [kworker/2:0-events_freezable_power_]
17491 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.04 % [kworker/2:4-events_freezable_power_]
 7656 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.02 % [kworker/0:2+events]
 1677 be/4 root        0.00 B/s    3.89 K/s  0.00 %  0.00 % X :0 -seat seat0 -auth /run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
Unterschiedlich im Idle-Vergleich sind hier nur:
udisksd & systemd-udevd

SSD: (sda1 = /; sda2 = SWAP; sda3 = /home)
 
OP
Christina

Christina

Moderator
Teammitglied
Code:
udisksctl unmount -b /dev/sdh1 && udisksctl power-off -b /dev/sdh1
So muss es richtig heißen.
Ich klicke nur den "Eject"-Button in Thunar oder Nautilus an. Das USB-Laufwerk wird damit komplett entfernt, also per lsblk auch nicht mehr angezeigt. (Das hat mit dem Aufwecken der internen HDD aber nichts zu zun. Da genügt unmount.)
 
Schalte udiskd ab, nur um das Problem einzugrenzen.
Vergewissere dich, dass er auch wirklich gestoppt ist und bleibt!
Test
# umount ..
Problem noch immer da?
Dann sehen wir uns udevd an
 

terceiro

Newbie
Bonjour

Nicht schlagen wenn ich mich hier auch noch einbringe.
Sonst einfach sagen "halt dich raus"

Können nicht damit die default Regeln der Dateien eingesehen werden ?
Code:
/usr/lib/udev/rules.d/*

Beziehungsweise der Hilfsprogramme.
Code:
/usr/lib/udev/*

Um das einzugrenzen.

au revoir
 
OP
Christina

Christina

Moderator
Teammitglied
Code:
systemctl stop udisks2.service
… entfernt das USB-Laufwerk TOSHIBA7 vom XFCE-Desktop und aus dem Thunar-Filemanager.
Das USB-Pendrive bleibt aber unter /run/media/{user}/TOSHIBA7 eingehängt, und ein Zugriff auf eine Datei ist möglich.
Code:
umount /dev/sdh1
hängt das USB-Laufwerk aus. Die HDD (/dev/sdb) bleibt jetzt im Standby.
Code:
systemctl start udisks2.service
… weckt die interne HDD auf, das USB-Laufwerk erscheint wieder auf dem Desktop, bleibt aber blass, also unmounted.
Wenn die HDD 10 Min. später im Standby ist, weckt ⏏ in Thunar oder udisksctl power-off -b /dev/sdh1 die HDD nicht auf.

@terceiro
Es gibt kleine Unterschiede in /usr/lib/udev/rules.d/ zwischen der Leap 15.3 Neuinstallation und dem Online-Upgrade von Leap 15.2 → 15.3. Ob die relevant sind, kann ich nicht sagen.
Siehe: https://paste.opensuse.org/89375626 – Einfach mal z.B. mit Meld (visual diff and merge tool) vergleichen.
 
Oben