Until lately I have used /etc/pm/sleep.d/ to place hooks for suspending (Mageia Cauldron). This can be necessary to disconnect and reconnect from a network service upon suspend or to restore the xrandr configuration after resume.
Now I have installed Mageia 8 from scratch and the pm-utils package was not installed by default any more. I have installed it manually but the /etc/pm/ suspend hook directory it provides is ignored. Also none of pm-utils hooks at /usr/lib64/pm-utils/sleep.d/ seem to get executed. I have tried it out by moving my /etc/pm-sleep hook there. Once again I had a look at my old Cauldron installation and pm-utils does not seem to be provided there any more too.
If pm-utils is installed as provided it should also become functional. Or what is now the prefferred method for suspend and resume hooks?
Also when experimenting with suspend I have found that the entries in /etc/systemd/sleep.conf seem to be ignored, too:
You can change "#HibernateMode=platform shutdown" into "HibernationMode=shutdown" which may be required for elder computers but if you "cat /sys/power/disk" after boot it will always says "platform" no matter the setting in systemd/sleep.conf. systemctl suspend/hibernate is likely the preferred method for suspending now and its configuration should not be ignored.
> rpm -q pm-utils systemd
list of related issues: https://bugs.mageia.org/show_bug.cgi?id=30180
Last release for pm-utils was in 2010.
Many rpm based distries already deprecated pm-util support in 2013.
Nowadays suspend/resume/hibernate is handled by systemd/systemctl.
In fact, Mageia is the only actual distribution which still drag around a dead pm-utils:
(In reply to sturmvogel from comment #2)
> Last release for pm-utils was in 2010.
> Many rpm based distries already deprecated pm-util support in 2013.
> Nowadays suspend/resume/hibernate is handled by systemd/systemctl.
(In reply to sturmvogel from comment #3)
> In fact, Mageia is the only actual distribution which still drag around a
> dead pm-utils:
Changing the summary and adding to the "packages to be obsoleted" tracker.
Mageia 9See Also:
pm-utils: suspend hooks are ignored =>
pm-utils and pm-fallback-policy need to be obsoleted (was:pm-utils: suspend hooks are ignored)
I don´t know if deprecating pm-utils is the solution. I could make a systemd.service that invokes the scripts in pm-utils. Pm-utils contains some legacy code to make suspend work on old an incompatible machines, like vbetool --post. Until a month or so ago the package was still functional but I do not know how the programs there were invoked by systemctl suspend.
(In reply to Elmar Stellnberger from comment #5)
> I don´t know if deprecating pm-utils is the solution.
pm-utils was deprecated 10 years ago by all distributions except Mageia (maybe forgotten to?). See also https://bugs.mageia.org/show_bug.cgi?id=30163#c10
Removing the package from the default installs should be fine. My question was, whether I should try to re-enable the suspend hook processing for optionally enabled scripts. As said pm-suspend will likely not work without it on some elder machines.
See the man pages for systemd-hibernate.service and systemd-sleep.conf
Also see the man page for systemctl, specifically for the commands hibernate,
hybrid-sleep, suspend, and suspend-then-hibernate.
Thx for the reference. All that needs to be done when invoking an old pm-util script is to my knowledge translate for $1: pre->suspend and post->resume. The other way round the scripts could be kept by suspend(pm-utils)->pre(systemd), resume->post if one enables to put them in /etc/systemd/sleep.conf.d/. The following unit file could also be adapted to execute more than one script:
cat >/etc/systemd/system/suspend-resume-dpconn-hook.service <<EOQ
Description=dpconn sleep hook
systemctl enable suspend-resume-dpconn-hook
The more clean solution would be to edit each script though I don´t think it will be worth the effort. However that still does not account for /etc/pm/config.d/defaults and /etc/pm/config.d/power.d.
If we are going to obsolete these packages, what happens to this bug? Do we simply leave it assigned to BugSquad? I see from comment 4 that you have already added it to the umbrella 'obsolete' bug.
(In reply to Lewis Smith from comment #10)
> If we are going to obsolete these packages, what happens to this bug? Do we
> simply leave it assigned to BugSquad? I see from comment 4 that you have
> already added it to the umbrella 'obsolete' bug.
I had hoped to obsolete those packages myself and then ask my mentor to push task-obsolete (or null, for packages that shouldn't be removed from user's systems), but time was lacking. It is better to assign them to all packagers collectively. For packages that do have a maintainer, it is best to assign to the registered maintainer.
Do this need to be a release blocker?
It's a release blocker for the final iso. If it's not removed before the
final is released, it can not be removed until Mageia 10.
pm-utils and pm-fallback-policy are obsoleted.