USB Festplatte mit hd-idle in den Standby

Systemd ist ein hassobjekt fuer mich, da krieg ich nix debugged, weil das alles so total kompliziert ist.
Denke aber mal nicht, das der jetzt ursaechlich fuer das Problem ist, bloss mein "systemd delenda est".

Disable halt mal hd-idle in systemd und starte das manuell mit denselben daemon parametern um systemd als problemquelle auszuschliessen.

Ich wuerde mal vermuten, das hd-idle als daemon gestartet nicht feststellen wird, das die platte idle ist, also nicht vom linux angefasst wird. Und deswegen die Platte nicht automatisch runterfaehrt.

Dasselbe solltest Du allerdings auch feststellen koennen wenn kein hd-idle laeuft, Du das so wie du das gemacht hast als one-time-trigger startest ... und dann wartest. Wenn da irgendwas im Linux die Platte anspricht, dann wird die ja wieder anlaufen.

Bei mir war das dann das komplexe Desktopsystem, was ja gerne USB Platten mit huebschen icons anzeigt, und die deswegen regelmaessig aufweckt. Hab das feate irgendwann mal abgeschaltet, frag mich aber nicht, wie. Auf jeden Fall leicht zu testen: Wenn platte immer wieder anlaeuft, einfach mal desktop stoppen und nur per CLI gucken was dann die platte macht.

wie gesagt, probier aus ob sie auch wieder anfaehrt, wenn kein desktop laeuft.
ansonsten kann es fuer den desktop auch einen unterschied machen, ob man die platte mountet oder nicht.

sagen wir mal das sdf die problematische platte ist.

while true ; do grep "sdf " /proc/diskstats; sleep 1 ; done

Das ist so ungefaehr was hd-idle macht um festzustellen, ob da irgenwas im Linux auf die Platte zugreift, und es legt die Platte bloss still, wenn das lange nicht passiert. Wuerde also mal ohne desktop und ohne laufendes hd-idle folgendes machen:

a) manuel mit hd-idle platte lahmlegen
b) script oben starten.

Jetzt gucken, ob sich die ausgabe aendert. Wenn ja, dann hat irgendwas im Linux an der platte was gemacht. Und dann ist es zu erwarten, das die aufwacht und das hd-idle die dann nicht wieder stilllegt.
Dann waere die schwierigere Aktion die Suche nach dem Uebeltaeter im Linux.

Wenn sich da nix tut, aber die Platte trotzdem aufwacht dann ist das USB gehaeuse Moppelkotze.

Wasn das fuer ein USB Gehaeuse ?

Zitat von te36

Dann waere die schwierigere Aktion die Suche nach dem Uebeltaeter im Linux.

iotop in Kombination mit lsof (grep auf mount-Point) waren in der Vergangenheit meine Mittel der Wahl (und geschicktes Greppen des /proc-Filesystems, wie bei dir)

smbd ist ein typischer Kandidat. Wenn noch irgendwo ein Client eine App offen hat, das ein directory-Listing überwacht.

Ist die Platte denn überhaupt dafür eingestellt, in den Ruhezustand zu gehen?
Ich hatte mir vor kurzem 2 externe Seagate geholt, beide waren so eingestellt, dass sie gar nicht erst in den Ruhezustand gehen konnten. Ich musste erst mit einem (von vier) bestimmten Seagate-Tool den idle-Modus aktivieren, und erst dann klappte das mit dem Ruhezustand. Der String dafür ist auf der HDD selber, NICHT dem Controller des externen Gehäuses abgelegt.
Vielleicht musste das bei deiner WD auch machen ?
Oder rede ich grade komlett am Thema vorbei ?

Gruß Gz

Die idle-Time konnte man mit den Tool auch auswählen bzw einstellen, 5min 10,15min usw... k.A. ob das mit nem Tool von WD auch geht bzw überhaupt eines gibt. Such doch mal nach sowas.

Gruß Gz

Das problem ist wohl eher, das irgendwas auf dem Linux system auf die Platte zugreift und die damit aufweckt.

wuerde ich von cron aus starten. einmal pro tag reicht.

Vielleicht hast du auch das gleiche Problem wie ich...
Seit dem Kernel größer 5.X wird vom System alle (ziemlich genau) 10min über den Dienst udisks2 ein Schreib-/Lesebefehl ausgestzt.
Deinstalliert man udisk2, funktioniert ein hd-idle Eintrag von mehr als 600sek wieder.
Auch die Verwendung von einem älteren kernel (z.B. http://4.19.XX/4.20.XX) trägt zur Lösung bei.
Habe auch schon einen Eintrag dazu auf github dazu gemacht und alles zugmal unter Debian Bullseye und Ubuntu 21.04 getestet.