Mounting an internally installed disk on a laptop spins up all disks connected to this machine via USB. And I try to prevent these externally connected disks to spin up.
The behaviour, IIRC, started a few months ago on the previous F27 and continues now on F28. Before that I don't remember this behaviour to have happened.
I thought it was some smartd issue, and stopped this service ("/usr/bin/systemctl stop smartd.service") - to no avail: mounting the internal disk still spins up the external ones.
The internal disk is identified by "smartctl -d test /dev/sda" like so:
[ ... ] /dev/sda: Device of type 'scsi' [SCSI] detected /dev/sda [SAT]: Device open changed type from 'scsi' to 'sat' /dev/sda [SAT]: Device of type 'sat' [ATA] opened
(On a side note: I'm astonished that a smartctl simple info flag is changing some device type like shown above)
External disks are identified by a smartctl test like so:
One: "[USB Sunplus]: Device of type 'usbsunplus' [ATA] detected"
the other one: "[SAT]: Device of type 'sat' [ATA] detected"
Anyone an idea about where to start investigating this issue? Where could such behaviour possibly be set up?
Thanks in anticipation.
Wolfgang
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?
If you are using gnome it just loves to seek out disks and access them any time any kind of a file dialog opens. This once worked, but may not any longer:
https://tomhorsley.com/game/case-of-disks.html
Also systemd seems to have an affinity for touching disks as well. I have a USB disk for backups that is normally not mounted, is listed in /etc/fstab with "noauto", 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.
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?
If you are using gnome it just loves to seek out disks and access them any time any kind of a file dialog opens.
Window Manager is Awesome WM, Display manager is GDM.
But there are some pieces of Gnome still running here as I still use Gnome apps occasionally on awesome ...
% ps ax | grep -i gnom[e] 1422 tty1 Ssl+ 0:00 /usr/libexec/gdm-wayland-session gnome-session --autostart /usr/share/gdm/greeter/autostart 1507 tty1 Sl+ 0:00 /usr/libexec/gnome-session-binary --autostart /usr/share/gdm/greeter/autostart 1522 tty1 Sl+ 0:18 /usr/bin/gnome-shell 1769 ? Sl 0:00 /usr/libexec/at-spi2-registryd --use-gnome-session 6777 ? Sl 0:00 /usr/bin/gnome-keyring-daemon --daemonize --login 7049 ? Sl 0:20 /usr/libexec/at-spi2-registryd --use-gnome-session 7127 ? Ssl 8:24 /usr/libexec/gnome-terminal-server 7391 ? Sl 0:00 /usr/bin/gnome-keyring-daemon --start --foreground --components=secrets
I'm running awesome on tty2, so gnome-shell on tty1 is still hanging around for whatever reason ..
This once worked, but may not any longer:
https://tomhorsley.com/game/case-of-disks.html
Also systemd seems to have an affinity for touching disks as well.
The external disks don't get mounted, they just spin up the moment I start acting, for example when manually mounting an internal HDD.
The behavior seems new: I run Fedora since ~2 yrs, and I noticed the USB disks spinning up only a few months ago - no changes since then that I'd remember of. And I don't think it's some hardware specific thing, as different disks show the same unwanted behavior.
One of those external disks even is spinning up after issuing this command:
------------- # smartctl -d sat -P show -n sleep,0 /dev/sdd smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.18.17-200.fc28.x86_64] (local build) Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org
Device is in SLEEP mode, exit(0) ------------
The 'n' flag above should make sure the disk isn't spun up when querying it, but nonetheless: the disk is rightly identified as being in sleep mode, but spins up anyways a second after issuing the command.
All I can do is manually spinning it down again: sdparm --readonly -C stop /dev/sdd
I'm still hoping there is a setting somewhere in /etc (or wherever) that controls this situation ...
I have a USB disk for backups that is normally not mounted, is listed in /etc/fstab with "noauto", 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).
I don't see any journalctl messages about the disks spun up, but I might find a setting for journalctl to log the behavior.
Not sure when it started happening, but it certainly didn't always happen because it is irritating enough to notice.
See? - so it seems it's not just me seeing this. So either there's some buggy piece of software somewhere, or some setting was changed at some point ....
Wolfgang
On 11/14/18 2:38 PM, Wolfgang Pfeiffer wrote:
Mounting an internally installed disk on a laptop spins up all disks connected to this machine via USB. And I try to prevent these externally connected disks to spin up.
Are the externally connected disks mounted?
/dev/sda: Device of type 'scsi' [SCSI] detected /dev/sda [SAT]: Device open changed type from 'scsi' to 'sat' /dev/sda [SAT]: Device of type 'sat' [ATA] opened
(On a side note: I'm astonished that a smartctl simple info flag is changing some device type like shown above)
Not really strange. /dev/sd* used to refer to SCSI disks, so it starts out assuming the drive is SCSI. After checking it, it determines that it's actually ATA and continues accordingly.
On 11/14/18 5:34 PM, Wolfgang Pfeiffer wrote:
I'm running awesome on tty2, so gnome-shell on tty1 is still hanging around for whatever reason ..
gdm is actually a special session of gnome-shell. gdm doesn't go away when you login.
Try running "sudo inotifywait -m /dev" before you do the mount and see if anything shows up. I think that will tell you if it's the kernel or some process. Another thing to try is doing it from a console or ssh when you aren't logged in to the graphical session.
On Wed, Nov 14, 2018 at 10:21:33PM -0800, Samuel Sieb wrote:
On 11/14/18 2:38 PM, Wolfgang Pfeiffer wrote:
Mounting an internally installed disk on a laptop spins up all disks connected to this machine via USB. And I try to prevent these externally connected disks to spin up.
Are the externally connected disks mounted?
No.
/dev/sda: Device of type 'scsi' [SCSI] detected /dev/sda [SAT]: Device open changed type from 'scsi' to 'sat' /dev/sda [SAT]: Device of type 'sat' [ATA] opened
(On a side note: I'm astonished that a smartctl simple info flag is changing some device type like shown above)
Not really strange. /dev/sd* used to refer to SCSI disks, so it starts out assuming the drive is SCSI. After checking it, it determines that it's actually ATA and continues accordingly.
Thanks. I already was suspecting it was something along this line ...
Wolfgang
On Wed, Nov 14, 2018 at 11:38:39PM +0100, Wolfgang Pfeiffer wrote:
Mounting an internally installed disk on a laptop spins up all disks connected to this machine via USB. And I try to prevent these externally connected disks to spin up.
The behaviour, IIRC, started a few months ago on the previous F27 and continues now on F28. Before that I don't remember this behaviour to have happened.
Solution: systemctl mask --now smartd
So far this seems to work, here on Fedora at least: on Debian (same computer, on a different disk) the problem seems to persist, in spite of doing something similar to what I did on Fedora - maybe a result of a different and even more buggy version on Debian. No idea, so far ...
I installed smartmontools, IINM, Jan 2017 - so I think this spinning up of disks over the last few months might be a bug due to a new version. Not being sure tho' ...
HTH
Regards, Wolfgang
On Sat, Nov 17, 2018 at 01:34:07AM +0100, Wolfgang Pfeiffer wrote:
The behaviour, IIRC, started a few months ago on the previous F27 and continues now on F28. Before that I don't remember this behaviour to have happened.
Solution: systemctl mask --now smartd
So far this seems to work, here on Fedora at least: on Debian (same computer, on a different disk) the problem seems to persist, in spite of doing something similar to what I did on Fedora - maybe a result of a different and even more buggy version on Debian. No idea, so far ...
I installed smartmontools, IINM, Jan 2017
.. on Fedora.
Wolfgang
On Sat, Nov 17, 2018 at 01:34:07AM +0100, Wolfgang Pfeiffer wrote:
On Wed, Nov 14, 2018 at 11:38:39PM +0100, Wolfgang Pfeiffer wrote:
Mounting an internally installed disk on a laptop spins up all disks connected to this machine via USB. And I try to prevent these externally connected disks to spin up.
The behaviour, IIRC, started a few months ago on the previous F27 and continues now on F28. Before that I don't remember this behaviour to have happened.
Solution: systemctl mask --now smartd
Sadly - wrong: Same problems again now, without having made any changes that I'd know of ..
Wolfgang
Answering to an old thread from a few months ago. It starts here: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org/...
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:
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
Allegedly, on or about 18 March 2019, Wolfgang Pfeiffer sent:
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 ..
Are there bookmarks to those locations in the file browser? Is it checking up on "recently" accessed places? Do you have the file-browser's sidebar listing other locations?
On 3/19/19 6:35 PM, Patrick O'Callaghan wrote:
On Mon, 2019-03-18 at 23:39 +0100, Wolfgang Pfeiffer wrote:
# btrace /dev/sdd &> /tmp/btrace.wi.udisks2.running.log
What is btrace? It doesn't seem to be in the standard repos and Google tells me it's a tracing tool for Java, which doesn't sound right.
[egreshko@meimei ~]$ dnf whatprovides btrace Fedora Modular 29 - x86_64 223 kB/s | 1.5 MB 00:06 Fedora 29 - x86_64 4.2 MB/s | 62 MB 00:14 RPM Fusion for Fedora 29 - Free 189 kB/s | 759 kB 00:04 RPM Fusion for Fedora 29 - Nonfree 52 kB/s | 221 kB 00:04 blktrace-1.2.0-7.fc29.x86_64 : Utilities for performing block layer IO tracing in : the Linux kernel Repo : fedora Matched from: Filename : /usr/bin/btrace
If anything runs any lvm commands it will basically run a pvscan internally and then that will also spin it up (I believe if not using lvmetad as with lvmedad it only does a single device at a time).
On Tue, Mar 19, 2019 at 5:47 AM Ed Greshko ed.greshko@greshko.com wrote:
On 3/19/19 6:35 PM, Patrick O'Callaghan wrote:
On Mon, 2019-03-18 at 23:39 +0100, Wolfgang Pfeiffer wrote:
# btrace /dev/sdd &> /tmp/btrace.wi.udisks2.running.log
What is btrace? It doesn't seem to be in the standard repos and Google tells me it's a tracing tool for Java, which doesn't sound right.
[egreshko@meimei ~]$ dnf whatprovides btrace Fedora Modular 29 - x86_64 223 kB/s | 1.5 MB 00:06 Fedora 29 - x86_64 4.2 MB/s | 62 MB 00:14 RPM Fusion for Fedora 29 - Free 189 kB/s | 759 kB 00:04 RPM Fusion for Fedora 29 - Nonfree 52 kB/s | 221 kB 00:04 blktrace-1.2.0-7.fc29.x86_64 : Utilities for performing block layer IO tracing in : the Linux kernel Repo : fedora Matched from: Filename : /usr/bin/btrace
-- Right: I dislike the default color scheme Wrong: What idiot picked the default color scheme _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
On Tue, 2019-03-19 at 18:46 +0800, Ed Greshko wrote:
On 3/19/19 6:35 PM, Patrick O'Callaghan wrote:
On Mon, 2019-03-18 at 23:39 +0100, Wolfgang Pfeiffer wrote:
# btrace /dev/sdd &> /tmp/btrace.wi.udisks2.running.log
What is btrace? It doesn't seem to be in the standard repos and Google tells me it's a tracing tool for Java, which doesn't sound right.
[egreshko@meimei ~]$ dnf whatprovides btrace Fedora Modular 29 - x86_64 223 kB/s | 1.5 MB 00:06 Fedora 29 - x86_64 4.2 MB/s | 62 MB 00:14 RPM Fusion for Fedora 29 - Free 189 kB/s | 759 kB 00:04 RPM Fusion for Fedora 29 - Nonfree 52 kB/s | 221 kB 00:04 blktrace-1.2.0-7.fc29.x86_64 : Utilities for performing block layer IO tracing in : the Linux kernel Repo : fedora Matched from: Filename : /usr/bin/btrace
OK. I had tried 'dnf search', which is my usual catch-all, and that didn't find it.
poc
On Tue, Mar 19, 2019 at 05:41:42PM +1030, Tim via users wrote:
Allegedly, on or about 18 March 2019, Wolfgang Pfeiffer sent:
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 ..
Are there bookmarks to those locations in the file browser?
Standard here is mc. That friendly file browser never tries to access stuff, unless i tell the guy to do so ... :) - or at least that's how I remember it.
Is it checking up on "recently" accessed places? Do you have the file-browser's sidebar listing other locations?
If you mean file *chooser*: I just tried it: with udisk2 running trying to download a file via Firefox does not spin up disks *currently* - I think I saw different behaviour in the past, where disks got spun up in such instances.
But that's not so much my actual problem. What is bothering me much more is the fact that connected HD's get spun up the moment I try to mount/unmount only one of them, as long as udisks2, it seems, is running. And this kills disks, plain and ugly, by running down their load cycles ..
Again: I solved this issue mostly by issuing systemctl stop udisks2
I already hinted it with a link to the SMART wiki in my last email: Hard Disks, depending on how they're made, have a limited number of those cycles: last time I saw somewhere between 300.000 and 600.000. Sometimes 10-20% more of them than the number predicted in the specs. But I can't rely on these extra cycles: I just try to make sure disks keep their precious heads down.
Oh, and I nearly forgot it: This isn't a specific problem with Fedora, as it seems: I saw some similar behaviour on Debian three or four months ago. Which is why I'm currently transitioning all my computers from systemd systems to non-systemd OS's. Not sure whether this will help, as of yet, sure: but software running down my hardware, without even giving me a reasonable chance to see what process is doing this is surely the famous straw on the camel's back. So yes: Debian, sooner or later, will find its way to the door here, too.
HTH.
Take care. Wolfgang
On Mon, Mar 18, 2019 at 11:39:43PM +0100, Wolfgang Pfeiffer wrote:
Looks like I found it: udisks2 seems to be the culprit.
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.
Or better: Nothing about udisks* ..
Wolfgang