hdparm not being triggered with udev

[Jools Wills]

Binary package hint: hdparm

Since hdparm was switched from init.d to being triggered by udev it has stopped working on my machine.
Originally I thought it was the missing rule for /dev/sdx disks but even with that change (https://bugs.launchpad.net/ubuntu/+source/hdparm/+bug/156893) it is not working right.

The bigger problem is I have no idea how to debug it, since nothing is outputted on boot in regards to it. I assume it is ran
during the initramfs stage? How should I check to see why it is not working?

my /etc/hdparm.conf has 4 lines like

/dev/disk/by-uuid/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx {
  spindown_time = 30
  apm = 1
}

and the problem is that the disks are not spinning down. This used to work fine when hdparm was run from init.d

I also tried using /dev/sda1 etc in case the /by-uuid symlinks were not available at the stage udev is triggering hdparm, but it made no difference. However I need to reference the disks by uuid (or label) as they may not always be on the same device. I thought the problem might also be to do with the disks being set to power on in standby mode, however after a reboot when they are spun up, the problem still occurs.

Another issue related to this is that there is no easy way to test your hdparm.conf. Before you could manually run the init.d script but this is no longer possible. I think this is not ideal, as hdparm configs can be quite complex, and a missing space between keyword and value etc can cause problems.

[Jools Wills (jools)]

Updated to intrepid and the problem still remains. I have to use debians init.d script to get my hdparm settings working.

There is still no obvious way of testing the hdparm.conf either as you cannot do /etc/init.d/hdparm to see that is works fine.

[Tormod Volden (tormodvolden)]

Note that by-uuid refers to partitions but you want to run hdparm on the device. There is usually also a device id in /dev/disk/by-id/

[Jools Wills (jools)]

I'll try that, but hdparm does work when pointing to a partition though (and just uses the underlying device).

[AmenophisIII (amenophisiii)]

imho i have the same problem in karmic now. it worked for me in jaunty (not sure why, and cant remember how it was in intrepid).

im trying to set the spindown timeout for my second disk with:

/dev/sdb {
 spindown_time = 240
}

but obviously it does not work.

all my / (but /boot) is encrypted, maybe this is related too?
will install the debian init script for now, if i can find it.

[Juhani Simola (ojs)]

I tried adding a debug log print to /lib/udev/hdparm to see which device name is used. Looks like it is never called for ATA drives.

Using device names under /dev/[hs]d[a-z] is still quite bad, as the device names may change.

[Mihai Osian (mihai-osian)]

  It appears that updating line 93 from /lib/udev/hdparm is enough to solve the issue.

Modify from:
   DISC=$KEY
to:
  DISC=$(readlink -f $KEY)

[AmenophisIII (amenophisiii)]

yes that works for me too (amd64, hdparm 9.15-1ubuntu4).

remaining problem for me: id like to use the "sleep" commando to put a drive into sleep mode (hdparm -Y) concurrently with setting the standby timer:
/dev/sdb {
 spindown_time = 240
 sleep
}

this gets executed with the patch, but the drive spins up instantly again. i dont fully understand the /lib/udev/hdparm script, but i guess the two commands i use are issued together and hdparm sends -Y before -S internally. this would explain the observed behaviour.
a fix for the script would handle -Y and -y commands differently (like it is done for -f (flush). a better way would be to ensure, that hdparm does issus -Y/-y last, if there are multiple command line issues in one call.
i should probably open another bug report?

[Mihai Osian (mihai-osian)]

Amenophis: I have just tested your configuration and what gets executed is the following:
    /sbin/hdparm -q -f /dev/sdb
    /sbin/hdparm -q -S240 -q -Y /dev/sdb
This instantly spins down the disk and sets the standby time at the same time. If your disk spins up again, then most likely something is accessing it. Check what partitions you have there. "lsof" might also be of help.

Mihai

[AmenophisIII (amenophisiii)]

hm yeah my presumption was wrong, and calling hdparm -q -S240 -q -Y /dev/sdb does set the time and put the drive to sleep without spinning it up instantly again. i should have tested that before, sorry.
question is, as mihai said, what does access the hd at that time. the partitions are encrypted and only used for backups, so there is no "normal" user-space program accessing it. only things like hald, gparted and there like wake the disk.
mihai: my configuration worked for you in a normal boot or did you test it another way? thanks.

[Mihai Osian (mihai-osian)]

  I tested it by enabling tracing in /lib/udev/hdparm (insert a "set -x" somewhere at the top), setting the "DEVNAME" variable to "/dev/sdb" and running the script. So no, it was not during a boot.

. But now that I think of it, it is quite possible that immediately after udev parses and sets the disk parameters other scripts will attempt to read the disk. I am not a specialist in udev, but I imagine that the sequence of operations is something like this:
  1. Detect disks (==> hdparm is called)
  2. For each disk, find partitions and read their UUIDs (==> disk is accessed again)
If that is the case, what you want may not be possible. You could do a quick test, though: comment out all the entries from /etc/fstab that point to partitions on that disk and see what happens. If that leaves the disk in standby after a reboot, try to add the "noauto" mount option to the fstab entries (of course, that means you will have to mount the partitions manually afterwards).

[christoph (fragfutter)]

running udev in debug mode (udevd --debug --debug-trace) i can see this execution order

1) /lib/udev/rules.d/50-udev-default.rules for sda
2) /lib/udev/rules.d/85-hdparm.rules for sda

3) /lib/udev/rules.d/50-udev-default.rules for sda1
4) /lib/udev/rules.d/85-hdparm.rules for sda1

in 2, the hdparm options get set, the disk goes to sleep. But in 3, blk_id is called against sda1, which spins up the disk again. 4 does not call hdparm.conf as it is a partition

[Stephane Epardaud (stef-inforealm)]

The suggestion from #6 works, and I hope it gets included in future versions of this package, since any local change will be overridden silently on upgrades (it's not in a config file)

[Vinny (vfuria)]

I also used the patch provided by Mihai Osian in comment #6 with success. Any chance of this making it into 11.04 (or sooner in an hdparm update?).

[Sundberg Pauli (susundberg)]

I confirm #6 working on fresh install (of linux mint 11, so i guess this is still open at 11.04) with minor modification: File is /lib/hdparm/hdparm-functions and line is 99.

[Sundberg Pauli (susundberg)]

I take my words back. The unmod

[Sundberg Pauli (susundberg)]

I take my words back. The unmodified file works as well. Setting 'set -x' and running the /lib/udev/hdparm function by hand does show that with DEVNAME=/dev/sda hdparm is called properly with options:
/sbin/hdparm -B254 -S1 /dev/sda

This does spin down the disk on manual run. After boot the disk is still not spinning down. After wake up from suspend the disk is spinning down.

it seems to me that /usr/lib/pm-utils/power.d/95hdparm-apm calls "/sbin/hdparm -B254" also, but this should not re-reset the spinning (at least not after manual run). I guess some other is messing up the spin down value -- gnome?

[Vinny (vfuria)]

@Sundberg Pauli (#17): Read the man page for hdparm. A -B option >128 disables spin-down (standby).

[Bob Harvey (bobharvey)]

Is this similar to Bug #595138 (10.04 LTS)