1

I'm running 12.04 on a home server/HTPC, and have several storage drives which spin down using values set in /etc/hdparm.conf.

Sometimes, logging in via ssh causes some or all of the drives to wake up. I set the udisks rule recommended in this post, and the spinning-up went from all the time to just some of the time.

I set audit rules, auditctl -w /dev/sde -p rwa -k e, for instance, to try to see what was waking them. Checking the audit results with ausearch, I see entries like this when I ssh in:

type=PATH msg=audit(04/16/2013 18:16:40.109:502) : item=0 name=/dev/sde inode=3010 dev=00:05 mode=block,660 ouid=root ogid=disk rdev=08:40 
type=CWD msg=audit(04/16/2013 18:16:40.109:502) :  cwd=/home/absqua 
type=SYSCALL msg=audit(04/16/2013 18:16:40.109:502) : arch=x86_64 syscall=open success=yes exit=3 a0=7fffcd697998 a1=800 a2=0 a3=0 items=1 ppid=14054 pid=14055 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=408 comm=hdparm exe=/sbin/hdparm key=e

So, my drives are being woken up by hdparm itself? How can I figure out what's calling it?

  • Working on 16.04, I'm trying sudo chmod -x /etc/update-motd.d/98-fsck-at-reboot an see if this works – MadMike Jun 20 '17 at 16:30
3

I was also struggling with this exact issue for a while, having tried audits, the mentioned udisks rule etc. But finally it was blktrace and blkparse that gave me the final hint of the problem: my sleeping disks were accessed by dumpe2fs on ssh login.

Apparently, the following script was the offender, scanning all drives to display which drives will be checked for errors at the next reboot on your motd at login.

/usr/lib/update-notifier/update-motd-fsck-at-reboot

The script only executes once every hour max, so that explains why it wasn't happening consistently. See lines 21-24:

if [ $(($stampt + 3600)) -lt $now ] || [ $stampt -gt $now ]; then
    #echo $stampt $now need update
        NEEDS_FSCK_CHECK=yes
fi

I decided to disable the automatic check on my system by replacing the variable assignation to : (do nothing). You could also increase the minimum time difference of 3600 seconds to something like a day or a week. But I found it preferable to run the script with --force during midnight maintenance when all my disks are awake anyhow. Since this script is purely informational it should be safe to just replace it with return 0 if you're not interested in this information.

I hope this helps anyone having the same or a similar issue. Even if it's another culprit on your system, I found blktrace and blkparse invaluable for diagnosing the problem.

  • I know I looked at motd, including the script you mention. dumpe2fs doesn't wake a sleeping disk when invoked manually, so I ruled it out. I'll take another look at it and blktrace and blkparse and come back with an update. Thanks! – absqua May 22 '13 at 12:26
  • Are you sure dumpe2fs doesn't wake up a sleeping disk? On my system (12.04.1 LTS) I consistently get a sleeping disk to wake up using sudo dumpe2fs -h. Note that I use hd-idle and apm=128 in my hdparm.conf for all my disks, since I have a few stubborn ones in my array that otherwise wouldn't go to sleep at all. Best of luck with your quest! – jvanhie May 25 '13 at 12:45
  • I tested dumpe2fs manually again, and it consistently woke each drive. Then I ran /usr/lib/update-notifier/update-motd-fsck-at-reboot --force, and it woke two of my four sleeping disks. Whatever. I took both of your suggestions—preventing the check on ssh login and forcing it with my nightly cron jobs—and the problem is fixed. Now I'll just have to remember to change that script after updates... Thank you for taking the time. – absqua May 25 '13 at 17:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.