Created attachment 846046 [details] pm-utils event test script Description of problem: Upon system events such as suspend, resume, hibernate, ac-power, battery-power, etc., pm-utils scripts in /etc/pm/power.d and /etc/pm/sleep.d are not executed by any component of systemd. Version-Release number of selected component (if applicable): systemd-208-9.fc20.x86_64 How reproducible: Always. Steps to Reproduce: 1. install pm-utils 2. store attached script to /etc/pm/power.d/10foo and /etc/pm/sleep.d/10foo 3. make them executable, ensure selinux context is correct 4. trigger a system event Actual results: Nothing. Expected results: Script output appearing in the system log and /var/log/pm-*.log Additional info: I have seen bits and pieces of an ongoing debate questioning pm-utils' usefulness here and there, mostly in the sense that systemd is now almighty and pm-utils should be dropped, but no clear documentation exists either from the systemd side (that is, how systemd provisions for pm-utils/hald combination that it is supposed to obsolete, in full scope) or from the Fedora Power Management Guide, which does not even mention anything regarding the current architecture and usability of system services in this relation. So at the very least, this is a documentation improvement request, if not a request to fix. On a side note, why keep pm-utils around at all? Why does a package still exist? At least it should produce a "WARNING: pm-utils will not work, it is obsolete" message in RPM preinstall script.
Yes, this should be documented better. There's some documentation in http://www.freedesktop.org/software/systemd/man/systemd-halt.service.html and http://www.freedesktop.org/software/systemd/man/systemd.special.html#sleep.target. pm-utils should probably be retired.
Thanks for the info, Zbigniew. I hope it is not yet too late to add a note about this to Release Notes, at the very least.
On another note... systemd does not have any AC/battery-related targets. This is not good, especially for laptop power users. By default, there are still about a thousand tunables Fedora does not touch when switching from AC to battery and same goes for tuned. There is no way of changing the current profile if there is no way of being notified AC status has changed. I'm guessing... missing feature? :) If you are to replace pm-utils/hald, then the full scope of its functionality should be provided for.
Is this something that could be implemented using ConditionACPower?
I figure it is up to the pm-utils maintainers to decide whether they want to retire the package or not. Reassigning. The "profile" for "tunables" thing of AC-vs.-battery is something we have discussed many times with the kernel folks, and always came to the same conclusion: what is good for battery usage, is good for AC too, and hence there's really no benefit in having two different profiles, and whatever makes sense should just be the default for all conditions. And the kernel defaults have slowly moved to that. Hence I am not convinced we really should support anything specific here in systemd; if you really want something like this, then please use tuned or some other tool, or just a drop-in or two in /etc/sysctl.d, but other than I don't think any infrastructure is needed.
(In reply to Lennart Poettering from comment #5) > I figure it is up to the pm-utils maintainers to decide whether they want to > retire the package or not. Reassigning. It is a package without hooks and as such, gloomy, sad and useless, sitting in a dark corner of the system. Its fate should probably be discussed some time *prior* to the actual release, ideally when decision has been made to drop hal and use systemd instead of it. I agree though that the honorary decision to retire a useless package is something that should probably be made by the maintainers. > what is good for battery usage, is good for AC too, and hence there's really > no benefit in having two different profiles, and whatever makes sense should > just be the default for all conditions. I have to disagree strongly. There are a number of tunables which sacrifice performance for improved autonomy when running on battery, including but not limited to: - decreased wireless range due to reduced TX power - slower CPU speed and/or less active CPU cores - decreased visibility due to reduced backlight level - interrupt clutter and expensive operations due to D0/D3cold switches etc. > And the kernel defaults have slowly moved to that. Hence I am not convinced > we really should support anything specific here in systemd; Think of it from the view point of a user - what do they do with their existing functionality and how long should they wait for the kernel defaults to slowly get where they need to be? > if you really want something like this, then please use tuned or some other > tool, or just a drop-in or two in /etc/sysctl.d, but other than I don't think > any infrastructure is needed. So it is your professional opinion we have been dealing with, and putting good use to, redundant system services for all these years? Kind regards, Grega
(In reply to Zbigniew Jędrzejewski-Szmek from comment #1) > Yes, this should be documented better. There's some documentation in > http://www.freedesktop.org/software/systemd/man/systemd-halt.service.html > and > http://www.freedesktop.org/software/systemd/man/systemd.special.html#sleep. > target. > > pm-utils should probably be retired. any idea - what is the systemd target to use when I need to run a script after resume from hibernation?
Hi, Richard. This was infact exactly my original point. Systemd does that improperly and insufficiently - retiring software without first providing for what the retired software was doing is very unprofessional, but unfortunately, also becoming a common practice. There are sleep and hibernate targets, but nothing that would handle a resume, much less differentiate the type of sleep the computer is waking up from. Missing functionality is *not* a pm-utils issue, but a systemd one.
I found /usr/lib/systemd/system-sleep/notify-upower.sh so it looks like it would be possible to get some of it done with systemd. However it seems me that it would be an evil totally undocumented hack to write configuration files into /usr/lib So if there is no better way to do it in systemd than it needs fixed. Also don't think it would be a good idea to throw pm-utils overboard. The /etc/sleep.d scripts were the best place for hardware specific or individual corner cases which can't be handled in a more generic way. This is exactly the case where systemd or any other framework provided by the distribution can not provide any advantage over the old pm-utils scripts - but imposes lots of work and inconvenience on users. So why do that?
Scripting around suspend is nothing we intend to support with systemd. THere's limited support for hooking in executables, but that's only a last-resort thing. It's documented in system-sleep(8). But anyway, scripting around the stuff will not come back. Sorry. We try to find generic solutions that work for everybody, and we don't solve things with script hacks anymore. If there's something to fix or improve, then we will find generic solutions that work for everybody, but userspace hacks is something we won't do.
Dropping the stale needinfo. If our input is still needed, please set the needinfo again.