Bug#725284: hdparm + systemd: Patch to restore configuration after resume
Hi, This doesn't guarantee that the service is run on resume. Those targets are activated on suspend/hibernate, so there is a race and you might actually run /usr/lib/pm-utils/power.d/95hdparm-apm *before* the system is suspended. You'd have to order this service after the *service* which does the actual suspend. Ouch. Thanks for the review. What does upstream recommend to do? Even though upstream recommends against shipping a snippet in /lib/systemd/system-sleep/ and considers them hacks, I actually think this is the cleanest/simplest solution here $ cat /lib/systemd/system-sleep/hdparm #!/bin/sh case $1 in post) /usr/lib/pm-utils/power.d/95hdparm-apm resume ;; esac [1] man systemd-sleep I found the following in the Arch wiki: https://wiki.archlinux.org/index.php/Power_management#Suspend.2Fresume_service_files. Superficially, that looks very similar to the hdparm service file proposed above (and I think I remember looking at the Arch Wiki when I tried to fix hdparm). Essentially, they are suggesting two different kinds of hooks: [Unit] Description=Local system resume actions After=suspend.target [Service] Type=simple ExecStart=/usr/bin/on-resume [Install] WantedBy=suspend.target That looks like it has exactly the same race? [Unit] Description=Some sleep hook Before=sleep.target StopWhenUnneeded=yes [Service] Type=oneshot RemainAfterExit=yes ExecStart=-/usr/bin/on-suspend ExecStop=-/usr/bin/on-resume [Install] WantedBy=sleep.target This looks different, but that may be just superficial. Kind regards, Ralf -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725284: hdparm + systemd: Patch to restore configuration after resume
Am Tue, 21 Apr 2015 14:53:36 +0200 schrieb Michael Biebl bi...@debian.org: This doesn't guarantee that the service is run on resume. Many thanks for your help in solving this, Michael! (Unfortunately, I had only tried the imperfect unit file, and I had just luck (or not) so that I did not see it fail.) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725284: hdparm + systemd: Patch to restore configuration after resume
On Wed, 25 Dec 2013 17:33:04 +0100 Ralf Jung p...@ralfj.de wrote: Dear maintainer, adding the attached systemd unit fixes restoring the hdparm configuration when systemd is used. I'd appreciate if you could add this (or a similar solution) to the package. This proposed patch doesn't work as-is, due to a misunderstanding how targets work: After=suspend.target After=hibernate.target After=hybrid-sleep.target This doesn't guarantee that the service is run on resume. Those targets are activated on suspend/hibernate, so there is a race and you might actually run /usr/lib/pm-utils/power.d/95hdparm-apm *before* the system is suspended. You'd have to order this service after the *service* which does the actual suspend. Even though upstream recommends against shipping a snippet in /lib/systemd/system-sleep/ and considers them hacks, I actually think this is the cleanest/simplest solution here $ cat /lib/systemd/system-sleep/hdparm #!/bin/sh case $1 in post) /usr/lib/pm-utils/power.d/95hdparm-apm resume ;; esac [1] man systemd-sleep -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#725284: hdparm + systemd: Patch to restore configuration after resume
Hi, The specific one you posted above could probably use oneshot: [Service] Type=oneshot Thanks! I'm not sure if I want anything to wait for hdparm being done with this (which seems to be the only consequence), but in any case it sounds more appropriate to what that unit is doing. Kind regards, Ralf -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725284: hdparm + systemd: Patch to restore configuration after resume
I don't know whether udev just doesn't trigger after a resume Either a generic systemd unit file is required to trigger an udev change event http://bugs.debian.org/779412, or a hdparm specific one to trigger just the hdparm script. The specific one you posted above could probably use oneshot: [Service] Type=oneshot -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725284: hdparm + systemd: Patch to restore configuration after resume
Hi again, I did some quick debugging, and it seems like the script /lib/udev/hdparm is never even run on suspend-resume. I'm not really familiar with udev, so I don't know whether udev just doesn't trigger after a resume, or whether there's some other problem here. The second mail in this bug contains a systemd unit that, when enabled, makes things work just fine for me. Kind regards, Ralf On 24.02.2015 12:28, Michael Meskes wrote: I just uploaded 9.43-2 with the patch mentioned in this bug report. However, I lack the hardware to test hdparm. So please test it before I file an unblock request. Also I'm not sure if it's a wise idea to remove the init file at this stage of the release. Thanks. Michael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725284: hdparm + systemd: Patch to restore configuration after resume
Hi again, sorry for the noise. This is just to confirm that there simply is no event for the disks on resume: $ sudo udevadm monitor -uk monitor will print the received events for: UDEV - the event which udev sends out after rule processing KERNEL - the kernel uevent KERNEL[49453.633973] change /devices/platform/regulatory.0 (platform) UDEV [49453.639612] change /devices/platform/regulatory.0 (platform) KERNEL[49455.504885] remove /devices/system/machinecheck/machinecheck1 (machinecheck) KERNEL[49455.504909] remove /devices/system/machinecheck/machinecheck2 (machinecheck) KERNEL[49455.504921] remove /devices/system/machinecheck/machinecheck3 (machinecheck) KERNEL[49455.504932] add /devices/system/machinecheck/machinecheck1 (machinecheck) KERNEL[49455.504943] add /devices/system/machinecheck/machinecheck2 (machinecheck) KERNEL[49455.504954] add /devices/system/machinecheck/machinecheck3 (machinecheck) KERNEL[49455.504970] change /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/ACPI0003:00/power_supply/AC0 (power_supply) KERNEL[49455.505011] change /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/PNP0C0A:00/power_supply/BAT0 (power_supply) KERNEL[49455.505032] change /devices/pci:00/:00:02.0/drm/card0 (drm) KERNEL[49455.505048] remove /devices/pci:00/:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.0/bluetooth/hci0/rfkill11 (rfkill) KERNEL[49455.505061] remove /devices/pci:00/:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.0/bluetooth/hci0 (bluetooth) KERNEL[49455.505072] add /devices/pci:00/:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.0/bluetooth/hci0 (bluetooth) KERNEL[49455.505086] add /devices/pci:00/:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.0/bluetooth/hci0/rfkill12 (rfkill) KERNEL[49455.505101] change /devices/pci:00/:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.0/bluetooth/hci0/rfkill12 (rfkill) UDEV [49455.509039] remove /devices/system/machinecheck/machinecheck3 (machinecheck) UDEV [49455.509067] remove /devices/pci:00/:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.0/bluetooth/hci0/rfkill11 (rfkill) UDEV [49455.509083] add /devices/system/machinecheck/machinecheck3 (machinecheck) UDEV [49455.509098] remove /devices/pci:00/:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.0/bluetooth/hci0 (bluetooth) UDEV [49455.509120] change /devices/pci:00/:00:02.0/drm/card0 (drm) UDEV [49455.509132] remove /devices/system/machinecheck/machinecheck2 (machinecheck) UDEV [49455.509142] add /devices/system/machinecheck/machinecheck2 (machinecheck) UDEV [49455.510170] change /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/ACPI0003:00/power_supply/AC0 (power_supply) UDEV [49455.510414] remove /devices/system/machinecheck/machinecheck1 (machinecheck) UDEV [49455.512911] add /devices/system/machinecheck/machinecheck1 (machinecheck) UDEV [49455.517673] change /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/PNP0C0A:00/power_supply/BAT0 (power_supply) UDEV [49455.745672] add /devices/pci:00/:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.0/bluetooth/hci0 (bluetooth) UDEV [49455.747898] add /devices/pci:00/:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.0/bluetooth/hci0/rfkill12 (rfkill) UDEV [49455.748665] change /devices/pci:00/:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.0/bluetooth/hci0/rfkill12 (rfkill) KERNEL[49455.751924] change /devices/pci:00/:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.0/bluetooth/hci0/rfkill12 (rfkill) UDEV [49455.752508] change /devices/pci:00/:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.0/bluetooth/hci0/rfkill12 (rfkill) KERNEL[49463.399317] change /devices/platform/regulatory.0 (platform) UDEV [49463.409976] change /devices/platform/regulatory.0 (platform) Using udev on system boot is probably still the right thing to do, but it won't help on this issue, Kind regards, Ralf -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725284: hdparm + systemd: Patch to restore configuration after resume
Hi, I just uploaded 9.43-2 with the patch mentioned in this bug report. However, I lack the hardware to test hdparm. So please test it before I file an unblock request. This doesn't seem to work: After suspend-resume, my disk behaves as if hdparm was not run at all. I did not yet investigate further. Everything worked fine with using a systemd unit that triggers the hdparm hook after resume. Kind regards, Ralf -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725284: hdparm + systemd: Patch to restore configuration after resume
I just uploaded 9.43-2 with the patch mentioned in this bug report. However, I lack the hardware to test hdparm. So please test it before I file an unblock request. Also I'm not sure if it's a wise idea to remove the init file at this stage of the release. Thanks. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725284: hdparm + systemd: Patch to restore configuration after resume
On Wed, 25 Dec 2013 17:33:04 +0100 Ralf Jung p...@ralfj.de wrote: adding the attached systemd unit fixes restoring the hdparm configuration when systemd is used. I'd appreciate if you could add this (or a similar solution) to the package. I second this (works for me), although I suppose it would be even better with Type=oneshot since it is not starting a daemon (works for me too). BTW even if the udev-based solution looks smarter, adding this unit would at least restore the exepected behaviour. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
