4:38 p.m.
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
5:48 p.m.
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.
7:34 p.m.
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
12:31 a.m.
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.
5:39 p.m.
Answering to an old thread from a few months ago. It starts here:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.o...
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
2:11 a.m.
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?
--
[tim@localhost ~]$ uname -rsvp
Linux 4.16.11-100.fc26.x86_64 #1 SMP Tue May 22 20:02:12 UTC 2018 x86_64
Boilerplate: All mail to my mailbox is automatically deleted.
There is no point trying to privately email me, I only get to see
the messages posted to the mailing list.
This email has been brought to you by beetwix. Mmm, spewy!
Get some into you today.
8:06 p.m.
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
5:46 a.m.
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
8:20 a.m.
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(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)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
11:21 a.m.
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
4:39 p.m.
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
12:21 a.m.
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.
5:18 a.m.
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
6:34 p.m.
New subject: [Solved, hopefully] Re: Mounting internal disk spins up connected
external USB disks
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
6:40 p.m.
New subject: [Solved, hopefully] Re: Mounting internal disk spins up
connected external USB disks
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
8:02 a.m.
New subject: [Solved: Not] Re: Mounting internal disk spins up connected
external USB disks
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
1860
days inactive
1990
days old
16 comments
7 participants
participants (7)
-
Ed Greshko -
Patrick O'Callaghan -
Roger Heflin -
Samuel Sieb -
Tim -
Tom Horsley -
Wolfgang Pfeiffer