Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #203782 > unrolled thread

hdparm ignoring spindown_time in config when called with by-id symlink

Back to article view | Back to linux.debian.user

Contents

  hdparm ignoring spindown_time in config when called with by-id  symlink Andrea Borgia <andrea@borgia.bo.it> - 2019-01-01 20:40 +0100
    Re: hdparm ignoring spindown_time in config when called with by-id  symlink Reco <recoverym4n@enotuniq.net> - 2019-01-02 12:20 +0100
      Re: hdparm ignoring spindown_time in config when called with by-id  symlink Andrea Borgia <andrea@borgia.bo.it> - 2019-01-02 13:40 +0100
        Re: hdparm ignoring spindown_time in config when called with by-id  symlink Reco <recoverym4n@enotuniq.net> - 2019-01-02 14:40 +0100
          Re: hdparm ignoring spindown_time in config when called with by-id  symlink Andrea Borgia <andrea@borgia.bo.it> - 2019-01-02 16:00 +0100

#203782 — hdparm ignoring spindown_time in config when called with by-id symlink

Hi.


My PC has two disks, a NVME for Debian/testing and an old 2.5 drive for 
an OS that shall remain nameless :)

Since the 2.5 disc isn't at all used by Linux, I figured I might as well 
set a very aggressive spindown time of, say, 30s and I wrote this in 
hdparm.conf:

/dev/disk/by-id/ata-Hitachi_HTS543225A7A384____E2024242DBNGWJ_ {
     apm = 1
     spindown_time = 6
}

To check whether the entry was applied, first I manually set the 
spindown to 1 unit, that is 5s, woke the drive up with cfdisk, confirmed 
it was active with hdparm -C, waited 5s, confirmed it was in standby.
So if the drive sleeps just 5s I'll know the change was ignored.


Then I tried checking whether hdparm would work when run via udev, with 
the following command:
DEVNAME=/dev/disk/by-id/ata-Hitachi_HTS543225A7A384____E2024242DBNGWJ_ 
/lib/udev/hdparm  >> /tmp/hdparm.log 2>&1
(suggestion taken from: 
https://stackoverflow.com/questions/49841690/hdparm-conf-settings-dont-seem-to-run-at-boot)

No go:
/dev/disk/by-id/ata-Hitachi_HTS543225A7A384____E2024242DBNGWJ_:
  setting Advanced Power Management level to 0xfe (254)
  APM_level	= 254
More importantly, the drive is still on 5s spindown.
I've tried with the apm option and without, no changes.
I've manually verified the by-id link, checks out.


However, if I invoke the udev script with /dev/sdb, the output confirms 
it is working:
/dev/sdb:
  setting Advanced Power Management level to 0x01 (1)
  setting standby to 6 (30 seconds)
  APM_level	= 1



Now, the questions:
1) am I wrong in using the by-id link to achieve a stable configuration?
2) am I wrong in testing with the symlink instead of the real device name?
3) if not, should I file a bug on hdparm?


Other relevant bugs:
#725884: in my case, running hdparm manually works just fine, it's the 
udev script that seems to fail somehow
#795025: my drive does not return any error when hdparm is run with 
"verbose"
#880008: interesting...



Thanks,
Andrea.

[toc] | [next] | [standalone]

#203795

	Hi.

On Tue, Jan 01, 2019 at 08:39:13PM +0100, Andrea Borgia wrote:
> My PC has two disks, a NVME for Debian/testing and an old 2.5 drive for an OS that shall remain nameless :)
> 
> Since the 2.5 disc isn't at all used by Linux, I figured I might as well set a very aggressive spindown time of, say, 30s and I wrote this in hdparm.conf:
>
> Then I tried checking whether hdparm would work when run via udev, with the following command:
> DEVNAME=/dev/disk/by-id/ata-Hitachi_HTS543225A7A384____E2024242DBNGWJ_ /lib/udev/hdparm  >> /tmp/hdparm.log 2>&1
> (suggestion taken from: https://stackoverflow.com/questions/49841690/hdparm-conf-settings-dont-seem-to-run-at-boot)

What about this:

DEVNAME=/dev/disk/by-id/ata-Hitachi_HTS543225A7A384____E2024242DBNGWJ_ \
sh -x /lib/udev/hdparm  >> /tmp/hdparm.log 2>&1

> Now, the questions:
> 1) am I wrong in using the by-id link to achieve a stable configuration?

You might get a race here. by-id symlinks are created by udev, so it's
possible to call hdparm udev script before actual symlink creation.


> 2) am I wrong in testing with the symlink instead of the real device name?

I'd rather remove this HDD via /sys interface as it's unused.


> 3) if not, should I file a bug on hdparm?

I've tried to reproduce your problem, but 'sh -x' invocation with your
configuration file got me this:

/sbin/hdparm -B1 -S6 \
/dev/disk/by-id/ata-Hitachi_HTS543225A7A384____E2024242DBNGWJ_

I suspect that your problem cannot be explained by hdparm bug.

Reco

[toc] | [prev] | [next] | [standalone]

#203799

Il 02/01/19 12:15, Reco ha scritto:


> What about this:
> DEVNAME=/dev/disk/by-id/ata-Hitachi_HTS543225A7A384____E2024242DBNGWJ_ \
> sh -x /lib/udev/hdparm  >> /tmp/hdparm.log 2>&1

I had tried it, too, and it looks in line with the results:

+ set -e
+ [ -n /dev/disk/by-id/ata-Hitachi_HTS543225A7A384____E2024242DBNGWJ_ ]
+ . /lib/hdparm/hdparm-functions
+ [ -e /proc/cmdline ]
+ grep -wq nohdparm /proc/cmdline
+ raidstat=OK
+ [ -e /proc/mdstat ]
+ egrep -iq resync|repair|recover|check /proc/mdstat
+ [ OK = OK ]
+ hdparm_options 
/dev/disk/by-id/ata-Hitachi_HTS543225A7A384____E2024242DBNGWJ_
+ local 
WANTED_DISK=/dev/disk/by-id/ata-Hitachi_HTS543225A7A384____E2024242DBNGWJ_
+ local DISC= DEFAULT= DEF_QUIET= COMMAND_LINE=
+ local OPTIONS OPT_QUIET KEY SEP VALUE
+ egrep -v ^[[:space:]]*(#|$) /etc/hdparm.conf
+ hdparm_try_apm 
/dev/disk/by-id/ata-Hitachi_HTS543225A7A384____E2024242DBNGWJ_
+ [ -z  ]
+ udevadm info -n 
/dev/disk/by-id/ata-Hitachi_HTS543225A7A384____E2024242DBNGWJ_ -q property
+ sed -n s/^ID_PATH=//p
+ local ID_PATH=pci-0000:15:00.1-ata-2
+ [ -z  ]
+ udevadm info -n 
/dev/disk/by-id/ata-Hitachi_HTS543225A7A384____E2024242DBNGWJ_ -q property
+ sed -n s/^ID_ATA_FEATURE_SET_APM=//p
+ local ID_ATA_FEATURE_SET_APM=1
+ [ 1 = 1 ]
+ return 0
+ hdparm_is_on_battery
+ on_ac_power
+ [ 255 -eq 1 ]
+ hdparm_set_option -B254
+ local NEW_OPT= NEW_DEF=
+ test -n
+ DEFAULT=  -B254
+ read KEY SEP VALUE
+ [ -h /dev/disk/by-id/ata-Hitachi_HTS543225A7A384____E2024242DBNGWJ_ ]
+ readlink -m /dev/disk/by-id/ata-Hitachi_HTS543225A7A384____E2024242DBNGWJ_
+ DISC=/dev/sdb
+ DISC=/dev/sdb
+ OPTIONS=  -B254
+ OPT_QUIET=
+ read KEY SEP VALUE
+ hdparm_is_on_battery
+ on_ac_power
+ [ 255 -eq 1 ]
+ hdparm_set_option -B1
+ local NEW_OPT= NEW_DEF=
+ test -n /dev/sdb
+ test x-B != x-B
+ NEW_OPT=
+ OPTIONS=  -B1
+ read KEY SEP VALUE
+ hdparm_set_option -S6
+ local NEW_OPT= NEW_DEF=
+ test -n /dev/sdb
+ test x-B != x-S
+ NEW_OPT= -B1
+ OPTIONS= -B1  -S6
+ read KEY SEP VALUE
+ [ -z /dev/sdb ]
+ [ -n  -B1  -S6 ]
+ [ /dev/sdb = 
/dev/disk/by-id/ata-Hitachi_HTS543225A7A384____E2024242DBNGWJ_ ]
+ COMMAND_LINE=
+ read KEY SEP VALUE
+ [ -n   -B254 ]
+ echo -B254
+ return 0
+ OPTIONS=-B254
+ [ -n -B254 ]
+ /sbin/hdparm -B254 
/dev/disk/by-id/ata-Hitachi_HTS543225A7A384____E2024242DBNGWJ_

/dev/disk/by-id/ata-Hitachi_HTS543225A7A384____E2024242DBNGWJ_:
  setting Advanced Power Management level to 0xfe (254)
  APM_level	= 254
+ exit 0

(copypasted because I found out only later that Thunderbird could not 
attach files from /tmp because of AppArmor)


>> 1) am I wrong in using the by-id link to achieve a stable configuration?
> You might get a race here. by-id symlinks are created by udev, so it's
> possible to call hdparm udev script before actual symlink creation.

Right, I had not considered that. However, in real life it seems to be 
working: I rebooted to check the DEVNAME, the script is being called 
with the actual "sd" name (now /dev/sda, before /dev/sdb... I might have 
had a USB stick plugged in during the previous reboot)


>> 2) am I wrong in testing with the symlink instead of the real device name?
> I'd rather remove this HDD via /sys interface as it's unused.

Apart from the fact I don't know (yet) how to do that, what good would 
it do? I'm not worried about unauthorized access, I just want to spin it 
down in order to, possibly, preserve it. Would removing it via /sys 
achieve this goal? Other benefits to your suggestion?


>> 3) if not, should I file a bug on hdparm?
> I've tried to reproduce your problem, but 'sh -x' invocation with your
> configuration file got me this:
> /sbin/hdparm -B1 -S6 \
> /dev/disk/by-id/ata-Hitachi_HTS543225A7A384____E2024242DBNGWJ_
> I suspect that your problem cannot be explained by hdparm bug.

Hmm, you don't have that disk in your system so the readlink call in the 
script will return the by-id name unchanged (I've tried that) and the 
comparison isn't really valid, I'm afraid. What happens if you try with 
an existing "id" for your system?



To recap, persistent names in the config seem to be ok, but the script 
apparently must be invoked with the actual name. This is what udev does 
and it works.


Thank you, Reco, for your help.

I'm CC'ing the maintainer for one quick feedback, if possible: SNAFU on 
my part, right?



Regards,
Andrea.

[toc] | [prev] | [next] | [standalone]

#203801

	Hi.

On Wed, Jan 02, 2019 at 01:34:14PM +0100, Andrea Borgia wrote:
> Il 02/01/19 12:15, Reco ha scritto:
> 
> > What about this:
> > DEVNAME=/dev/disk/by-id/ata-Hitachi_HTS543225A7A384____E2024242DBNGWJ_ \
> > sh -x /lib/udev/hdparm  >> /tmp/hdparm.log 2>&1
> 
> I had tried it, too, and it looks in line with the results:

Good news are - your configuration file comes into play:

> + OPTIONS= -B1  -S6

Bad news are - /lib/hdparm/hdparm-functions screws you over:

> + read KEY SEP VALUE
> + [ -z /dev/sdb ]
> + [ -n  -B1  -S6 ]
> + [ /dev/sdb = /dev/disk/by-id/ata-Hitachi_HTS543225A7A384____E2024242DBNGWJ_ ]

This corresponds to line 222 of aforementioned script:

	if [ -n "$OPTIONS" ] && [ "$DISC" = "$WANTED_DISK" ]
	then
		echo $OPTIONS
		return 0
	fi

You have options defined, but second comparison fails. $DISC seems to be
defined at line 113:

	DISC=$(readlink -m "$KEY")
	DISC=${DISC%%[[:digit:]]*}

And readlink 'helpfully' transforms your 'persistent' HDD name to
/dev/sdb.

So udev is not to blame here. It's shell-based config parsing library.


> (copypasted because I found out only later that Thunderbird could not attach files from /tmp because of AppArmor)

Whitelist it. A file should be called
/etc/apparmor.d/local/usr.bin.thunderbird.



> > > 2) am I wrong in testing with the symlink instead of the real device name?
> > I'd rather remove this HDD via /sys interface as it's unused.
> 
> Apart from the fact I don't know (yet) how to do that, what good would it do?

echo 1 > /sys/block/sdb/device/delete

Assuming that your SATA controller is sane, it'll powerdown the drive
until the next reboot or SATA bus scan.

Reco

[toc] | [prev] | [next] | [standalone]

#203807

Il 02/01/19 14:35, Reco ha scritto:


> So udev is not to blame here. It's shell-based config parsing library.

Possibly an upstream issue for hdparm, then.
Nice :(


> Whitelist it. A file should be called
> /etc/apparmor.d/local/usr.bin.thunderbird.

Thanks for the tip, saving for later.


> echo 1 > /sys/block/sdb/device/delete
> Assuming that your SATA controller is sane, it'll powerdown the drive
> until the next reboot or SATA bus scan.

Interesting!

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web