[arch-general] systemd, running scripts after suspend/hibernate
I have made the jump to systemd and I have been ironing a few things here and there, one of them is setting the HD advanced power management to a sane level to avoid excessive wear due to constant head parking. I've been able to achieve this by placing my script in /usr/lib/systemd/system-sleep, however 'man systemd-sleep' says: "Note that scripts or binaries dropped in /usr/lib/systemd/system-sleep/ are intended for local use only and should be considered hacks." This seems to imply that a service file should be used, what I can't figure out from the documentation or google searches is how to implement the functionality I want with a .service file, or if a service file is actually needed/recommended. Any pointers or help are welcome. -- Mauro Santos
On Tue, Oct 2, 2012 at 12:01 PM, Mauro Santos <registo.mailling@gmail.com> wrote:
This seems to imply that a service file should be used, what I can't figure out from the documentation or google searches is how to implement the functionality I want with a .service file, or if a service file is actually needed/recommended.
The way I read it is that the sort of problems you would typically workaround with suspend hooks are best solved somewhere else, probably in the kernel driver. -t
On 02-10-2012 11:12, Tom Gundersen wrote:
On Tue, Oct 2, 2012 at 12:01 PM, Mauro Santos <registo.mailling@gmail.com> wrote:
This seems to imply that a service file should be used, what I can't figure out from the documentation or google searches is how to implement the functionality I want with a .service file, or if a service file is actually needed/recommended.
The way I read it is that the sort of problems you would typically workaround with suspend hooks are best solved somewhere else, probably in the kernel driver.
-t
Fair enough, then I'll keep it as I have it now, thanks for the input. -- Mauro Santos
Am Tue, 2 Oct 2012 12:12:24 +0200 schrieb Tom Gundersen <teg@jklm.no>:
The way I read it is that the sort of problems you would typically workaround with suspend hooks are best solved somewhere else, probably in the kernel driver.
That's so typical for those Poetterix fanboys and developers. Firstly ALSA was blamed for the PulseAudio insufficiencies and bugs. ALSA was blamed for PulseAudio not working with a lot of professional audio and sound cards even if ALSA supported them perfectly by default out-of-the-box since years. Now the Linux kernel is blamed for the systemd insufficiencies and bugs. That's really funny. *rofl* I take my popcorn. Heiko
Am Tue, 2 Oct 2012 13:28:40 +0200 schrieb Heiko Baums <lists1@baums-on-web.de>:
That's so typical for those Poetterix fanboys and developers.
Firstly ALSA was blamed for the PulseAudio insufficiencies and bugs. ALSA was blamed for PulseAudio not working with a lot of professional audio and sound cards even if ALSA supported them perfectly by default out-of-the-box since years.
Now the Linux kernel is blamed for the systemd insufficiencies and bugs. That's really funny. *rofl*
I take my popcorn.
And btw. ... So much about the very effective banning. Yes, I was indeed banned, and like Allan told me, he wanted to ban me forever, because I sent him a few comments on his banning. *rofl* That's really censorship, arrogance and ignorance. Just ban everyone who has a different opinion, because of his own experiences. If you really want to improve Arch Linux have a look at runit if you don't want to keep sysvinit. That looks a lot easier, cleaner and clearer than systemd from what I've read in its documentation. But, hey, Arch Linux is KISS, so why using simple and easy solutions if we could have complicated crap like systemd? Heiko
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 02.10.2012 13:36, schrieb Heiko Baums:
And btw. ...
So much about the very effective banning. Yes, I was indeed banned, and like Allan told me, he wanted to ban me forever, because I sent him a few comments on his banning. *rofl*
That's really censorship, arrogance and ignorance. Just ban everyone who has a different opinion, because of his own experiences. ...
=full ack! it's like in "real life": incompetence of "authorities" and they only succeed as intimidation of masses succeed. Tell me if you need more accounts; I have access to several accounts/domains. I originally wasn't plannin to interfere into this "flamewar", even might be willing to test systemd in my vm (although seems to be crappy bloatware and nothing more or less) and there have been lot of constructive discussion on this list from both devs and critical users within the last days (future of initscripts...), but admin robots like Allan are a serious danger for community projects and freedom of speech in the "virtual world" in general and if we as community let us control by them and won't shut our mouths we might end up like e.g. German Wikipedia. So my question: Who has voted for Allan as robot/admin/supervisor/root/dictator of this platform and who does control him? Cheers, Jakob -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIbBAEBAgAGBQJQa5mJAAoJEOl7hkDId7Ymj9oP93zmL9miaUfhve5aMq2HDA6v wqMkaSKDAN/TZZJhYklJQUkWl7BMV7nIJVGYVlGAG1jWCW6MPF8X5jS/UF10pKm4 Z1tabeP3BcJbDSSE9TMoeE1+9lnM3bhhHGBKJqs8iq+0V6XpeLT6cojnnvaFUEDa p+f3VHFNlXNInFvGwdk+X5BYubnaIEYAH0HTQPJ6Fq7I9KQtpfEjgRuA8w1vVv55 9Cx6mZjn0Kz0FpfcP0MN9QMkmNCFwWAR+A35Gzx57GoyMhwY21aJLsywpxd4KWPR kyOp6FGJxaZ1jN6Ob0iAmfOhSG9Mw4ckt6oeK7NHur01wrvlOB9RsqhgG8+CtfMN H6gokrU9NG7zBdSmNsCZBPDJPGX1pZr+YxfcE7dEznq3ljqX/3BmjsScakXvwDsE UEjfaMpJH+YsZ71H/7BiPUVulzEeO/PZ2izg+PGtDPgIHAAZLNqQge44RJ/V4S/5 DYrqTIC5xyJ/dkdcftiuc1Got/KUSqqEfoZ8MNlVKdaxMVP8VcLkbpbL2PRoxi0D puO+TNGSOCtJl3gQdi8X1PsD9DP5vBoV/mFUmAHSmybGbUtj2v1IklvsWXNAPtDX x3dIgNXaklFdLivxPd5OwxN4kGqZ8hBDx/49BaHjU21Rx1pk3pgZ4mO4HxuZ3D8s Y27VsR5tKeGEfP3RZSw= =KRMI -----END PGP SIGNATURE-----
Am 02.10.2012 13:28, schrieb Heiko Baums:
Am Tue, 2 Oct 2012 12:12:24 +0200 schrieb Tom Gundersen <teg@jklm.no>:
The way I read it is that the sort of problems you would typically workaround with suspend hooks are best solved somewhere else, probably in the kernel driver.
That's so typical for those Poetterix fanboys and developers.
[...]
Now the Linux kernel is blamed for the systemd insufficiencies and bugs. That's really funny. *rofl*
Actually, suspend hooks are _only_ used to work around kernel insufficiencies. They always were, nothing changed here. Only your perception of it changed. It's actually funny that a) your message proves once and for all that you are an idiot and a troll and b) you will not have much luck responding to this message.
On Tue, Oct 2, 2012 at 1:28 PM, Heiko Baums <lists1@baums-on-web.de> wrote:
The way I read it is that the sort of problems you would typically workaround with suspend hooks are best solved somewhere else, probably in the kernel driver.
[...]
Now the Linux kernel is blamed for the systemd insufficiencies and bugs.
In case there are still people out there who might take what Heiko writes seriously: The advice about trying to avoid scripts in systemd-sleep is not about passing the blame, nor is it due to bugs in systemd. The systemd-sleep logic provides the same features as the equivalent pm-utils hooks did, this means that we are no worse than before. No new bugs, no regressions, no missing features. That said, it is obvious by looking at what kind of hooks were written for pm-utils, that they are all hacks/workarounds for bugs that should have been fixed elsewhere. For this reason, we want to discourage people from using these hooks, and rather fix the bugs they are used to work around If it turns out that there are examples that are not actually bugs, but a valid use of these hooks (I have yet to see one), then the functionality is still there. Same if you just like using the hooks for silly things, or if fixing the relevant bugs is too hard for you. The functionality is there. There is really nothing to complain about. My apologies if I was unclear in my first email, and I hope that this leaves no room for misinterpretation. Cheers, Tom
On Tue, Oct 2, 2012 at 8:03 AM, Tom Gundersen <teg@jklm.no> wrote:
On Tue, Oct 2, 2012 at 1:28 PM, Heiko Baums <lists1@baums-on-web.de> wrote:
The way I read it is that the sort of problems you would typically workaround with suspend hooks are best solved somewhere else, probably in the kernel driver.
[...]
Now the Linux kernel is blamed for the systemd insufficiencies and bugs.
In case there are still people out there who might take what Heiko writes seriously:
The advice about trying to avoid scripts in systemd-sleep is not about passing the blame, nor is it due to bugs in systemd.
The systemd-sleep logic provides the same features as the equivalent pm-utils hooks did, this means that we are no worse than before. No new bugs, no regressions, no missing features.
That said, it is obvious by looking at what kind of hooks were written for pm-utils, that they are all hacks/workarounds for bugs that should have been fixed elsewhere. For this reason, we want to discourage people from using these hooks, and rather fix the bugs they are used to work around
If it turns out that there are examples that are not actually bugs, but a valid use of these hooks (I have yet to see one), then the functionality is still there. Same if you just like using the hooks for silly things, or if fixing the relevant bugs is too hard for you. The functionality is there. There is really nothing to complain about.
My apologies if I was unclear in my first email, and I hope that this leaves no room for misinterpretation.
Cheers,
Tom
Exactly, for example I need to use a systemd-sleep hook to workaround a bug in the kernel ehci_hcd driver. It had already been reported upstream (and it looks like it may be finally fixed in kernel 3.6!), but it took years for upstream to fix it, so I've always had to use a pm-utils or systemd-sleep hook. A local hack to workaround a bug until it was fixed upstream. I've had no problems so far with systemd-sleep hooks compared to pm-utils hook, it seems to have all the same functionality. I only had to change 2 lines on my pm-utils hook to make it work with systemd too.
participants (6)
-
Brandon Watkins
-
Heiko Baums
-
Jakob Herrmann
-
Mauro Santos
-
Thomas Bächler
-
Tom Gundersen