Answering to an old thread from a few months ago. It starts here:
https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx/message/NI76UZ33W72OA3POGL34IWBNWDXOS547/
On Wed, Nov 14, 2018 at 06:48:17PM -0500, Tom Horsley wrote:
On Wed, 14 Nov 2018 23:38:39 +0100
Wolfgang Pfeiffer wrote:
Anyone an idea about where to start investigating this issue? Where
could such behaviour possibly be set up?
Looks like I found it: udisks2 seems to be the culprit.
This seems to stop this dangerous nonsense [0]: after logging in to
a computer with systemd/usdisk2 on it I enter:
systemctl stop udisks2
I'd be careful tho' to mask it altogether, because I have no idea
how important udisks2 is for a successful system boot ...
If you are using gnome it just loves to seek out disks and
access them any time any kind of a file dialog opens.
Same here: but here not just with Gnome as a complete Dektop
Environment, but with Awesome WM, and the few programs like maybe file
chooser or other programs that are part of the Gnome universe but
still opened on awesome: So in these instances these disk spin-ups
even might happen after stopping udisks2 with the command from above.
This once worked, but may not any longer:
https://tomhorsley.com/game/case-of-disks.html
As you already suspected on that page: with udisks2 things have
changed again [1].
Also systemd seems to have an affinity for touching
disks as well.
udisks2 seems to be hard wired to systemd - the dependencies of the
package at least seem to show that.
The ugliest thing actually: the two tests below didn't show even
the slightest hints that udisks2 could be involved:
# btrace /dev/sdd &> /tmp/btrace.wi.udisks2.running.log
# inotifywait -m --format "%T %w %e %f" --timefmt "%H:%M:%S" /dev -o /tmp/inotify.wi.udisks.running
I started both tracers above with a running udisks2 service right
before I mounted an internal disk: /dev/sda. At that moment, as usual,
sadly, an external USB disk (dev/sdd), connected to the same computer,
same time, got spun up. The logs show nothing about what accessed
/dev/sdd.
If I hadn't been told recently it could be, IIRC, udev - which then
in turn lead me to udisks2 - I still wouldn't have any idea about
what's going on ...
I have a USB disk for backups that is
normally not mounted, is listed in /etc/fstab with "noauto",
Nothing mounted here automatically; the problem is that all disks
that seem to be in reach of the OS and not being fast enough to run away
as fast as they can, get accessed, and then spun up ..
yet recently I've noticed every time I reboot, I have
to wait for some systemd message about syncing headers on
disk [sdf] (which takes a while because the disk is
very slow and has to spin up first). Not sure when it
started happening, but it certainly didn't always
happen because it is irritating enough to notice.
Hoping it helps ...
Best Regards,
Wolfgang
[0] SMART ID 193:
https://en.wikipedia.org/wiki/S.M.A.R.T.
[1]
https://wiki.archlinux.org/index.php/udisks#Hide_selected_partitions
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
