Package Details: systemd-hddapm 1.6-1

Git Clone URL: https://aur.archlinux.org/systemd-hddapm.git (read-only)
Package Base: systemd-hddapm
Description: Hard Disk APM level service for systemd
Upstream URL: https://sourceforge.net/projects/hddapm
Licenses: GPL
Submitter: R00KIE
Maintainer: R00KIE
Last Packager: R00KIE
Votes: 14
Popularity: 0.159027
First Submitted: 2012-09-24 20:29
Last Updated: 2015-07-15 19:04

Latest Comments

R00KIE commented on 2013-06-01 11:25

You are right, there was no install message. I had the install file but forgot to add the install= line to the PKGBUILD. Package updated to show the install message.

stativ commented on 2013-06-01 09:08

R00KIE: There is no install message.

R00KIE commented on 2013-05-31 23:54

Did you try 'udevadm info -a -p $(udevadm info -q path -n /dev/sdx)' as stated in the install message?

diggit commented on 2013-05-31 11:23

Sorry, my bad. I had to re-enable it (disable, enable). Then was created missing symlink. One question, where to get correct identification string of device? (ATTRS{model}=="this string")

R00KIE commented on 2013-05-30 10:41

Did you try 'systemctl enable hddapm' and reboot?

diggit commented on 2013-05-29 16:41

My HDD has apm settings in default (128) after every wake up(when in was suspended). Is it possible to modify rule to set defined value after every wake up too?

diggit commented on 2013-05-29 16:26

My HDD has apm settings in default (128) after every wake up(when in was suspended). Is it possible to modify rule to set defined value after every wake up too?

R00KIE commented on 2013-05-25 20:10

This change makes the package more robust and flexible than it was before.

The package provides a rule that can be used as example, the install message explicitly says what the user should do and there is a wiki page about writing udev rules, there is enough information to point the user in the right direction.

PerfectGentleman commented on 2013-05-25 09:17

i should notice that editing udev rules is not simple for users

R00KIE commented on 2013-05-22 11:19

Yes, that is correct. You should edit the udev rule to match the hard disk you want to control. If you have more than one device just add more rules.

The benefit of using udev is that as devices show up they will be set to the proper APM level. This helps in the case where you use this in the initramfs and the hook runs too early and not all disks are ready and present yet.

Hot swapping, which I didn't consider initially should also work without problems.

PerfectGentleman commented on 2013-05-22 02:05

is /etc/hddapm.conf not needed anymore?

R00KIE commented on 2013-05-21 11:14

Paths updated to /usr/bin/*

stativ commented on 2013-05-20 15:51

There's a new hdparm being brewed in testing that has the hdparm binary moved from /sbin/hdparm to /usr/bin/hdparm.

Anonymous comment on 2013-01-29 17:15

Simply and great for WD Green series! Thanks!!!

gdamjan commented on 2012-11-07 00:06

This should probably be merged with the hdparm package in [core]

WonderWoofy commented on 2012-10-03 03:48

I didn't even think about the FDE use case. That is a good point though, maybe you are right that initramfs implementation is better since it would be of greater use to more people. I guess you also could have parking heads w/ a multi-disk setup if one is not being accessed on boot. My laptop has one HDD and one SDD, so I wasn't thinking about that either.

As far as a vendor utility, I think it would probably be best to try and stay away from anything propritary like that.

Regarding the udev rule, I am aware of the cons of using that method. Hence, I was willing to try your little package here. I think that I would just not run another daemon on my system if the only thing I am going to be using it for is setting the APM. This is especially the case with my awareness of alternative solutions. I have nothing against upower and if I had more uses for it, I would probaby consider it.

Anyway, thanks again, I will keep you posted if I discover any news that may help.

WonderWoofy commented on 2012-10-02 21:24

BTW, are you the one who started up the conversation about /usr/lib/systemd/system-sleep hooks and APM in Arch General (Marcos)? If not, you should be aware that there is a conversation (and trolling) going on there at the moment.

R00KIE commented on 2012-10-02 20:18

I was trying to avoid using an udev rule since it's harder to debug, the typical use case (I guess) is going to be to set the APM of the internal drive that comes with laptops, otherwise an udev rule would be more appropriate.

Currently I am setting the APM level in the initramfs, for my case this helps avoid one head park for each cold boot or resume from hibernation. I'm using full disk encryption, so the time it takes to input the password and get it verified is enough to let the HD do a head park.

Regarding the discussion in Arch General, I am aware of it, I subscribe that list. From one of the posts I really get the sense that putting a script in /usr/lib/systemd/system-sleep is the way to go, the alternative is to use a vendor utility to set the APM level and store it in the firmware.

As for the default value of the APM level, 255 should be the value to use to disable APM completely (according to 'man hdparm'), some disks don't seem to support it but as you say at least yours falls back to 254 and I suppose that would be the case for other disks too, as with other things the user is responsible for checking any applicable configuration files and doing any customization deemed necessary.

WonderWoofy commented on 2012-10-02 19:47

BTW, are you the one who started up the conversation about /usr/lib/systemd/system-sleep hooks and APM in Arch General (Marcos)? If not, you should be aware that there is a conversation (and trolling) going on there at the moment.

WonderWoofy commented on 2012-10-02 18:04

Yeah, I think reliability is the key here. I know about upower's abilities, but I much prefer to simply create what I need, rather than unnecessarily load something to do a single simple task.

I think a better way to set APM early is a udev rule. I guess the initramfs would be earlier, but I figure that there is no reason to set it that early, as the system is actively using the hdd at that time. The way I had it set before I found your package here, is match a udev rule to the desired drive, and when found simly run the hdparm command. Works flawlessly.

I was then simply using the system-sleep directory to reset it on wake, like your system here.

I think it is a good start, maybe with a bit more practical experience with systemd, a better solution will some along. For now, I am glad you have made a working system here.

R00KIE commented on 2012-10-02 11:24

I think I'll leave it as it is now, at least for a while. The feedback I got from one of the devs [1] is that it should be ok to use it like it is now, and hey, it works reliably :p

Another package (upower) also handles coming out of suspend/hibernate it with a script, if there was a better way to do things then I guess it would have been used.

I'm also planning to add a mkinitcpio hook so the APM can be set very early on, I suppose that will make the service file a bit redundant, I'll still ship the file but not enable the service by default, the user should choose which method to use.

As for the discussion, it's probably better to keep it here in the open.

[1] http://mailman.archlinux.org/pipermail/arch-general/2012-October/031384.html

WonderWoofy commented on 2012-10-02 06:43

Hey, sorry for all the comments, it seems to work once, and then stops... If you prefer that I contact you some other way, like email, let me know.

WonderWoofy commented on 2012-10-02 05:03

Hey, sorry for all the comments, it seems to work once, and then stops... If you prefer that I contact you some other way, like email, let me know.

WonderWoofy commented on 2012-10-02 04:54

Okay, now it is not working...

WonderWoofy commented on 2012-10-02 04:52

In hddapm.service, add "Also=hddapm-reapply.service" (assuming that is what you call the secondary service), and done!

WonderWoofy commented on 2012-10-02 04:40

Nevermind about the requires part, I am not sure exactly how to pull another service file with a given service file. I am perusing documentation, though the hddapm-reapply.service works.

WonderWoofy commented on 2012-10-02 04:35

All you have to do is make another service file that is required by hddapm.service.


cat hddapm-reapply.service
[Unit]
Description=Sets the Advanced Power Management level for the chosen Hard Disk
After=suspend.target

[Service]
Type=simple
ExecStart=/usr/bin/hddapm post
RemainAfterExit=yes

[Install]
WantedBy=suspend.target

WonderWoofy commented on 2012-10-02 04:10

That is a good point about the _after_ part of it. I remember reading somewhere that some drives have issues when you set it to 255. In fact, mine just drops it to 254 when I try 255. Maybe 254 would be a more sane default?

R00KIE commented on 2012-10-01 17:01

Added an option in the configuration file to select the device.

Running the script after suspend/hibernate was already taken care of, there is a symlink in /usr/lib/systemd/system-sleep to make it run after suspend/hibernate.

I have been looking into how to use only unit files and not rely on /usr/lib/systemd/system-sleep, but I haven't found any examples or information about it, any pointers will be welcome. Also sleep.target.wants doesn't exist on my system, only sleep.target, however my doubt would be how to properly hook it to run _after_ coming out of suspend/hibernate.

WonderWoofy commented on 2012-10-01 15:42

I think this is a good idea, but you should make a variable for the desired devce, instead of simply assuming it is going to be /dev/sda. Also, I think that it should be added to the sleep.target.wants, so that it will reapply the settings after it wakes. Good start though.