Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   ArchLinux General Discussion (http://www.linux-archive.org/archlinux-general-discussion/)
-   -   systemd, running scripts after suspend/hibernate (http://www.linux-archive.org/archlinux-general-discussion/708993-systemd-running-scripts-after-suspend-hibernate.html)

Mauro Santos 10-02-2012 10:01 AM

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

Tom Gundersen 10-02-2012 10:12 AM

systemd, running scripts after suspend/hibernate
 
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

Mauro Santos 10-02-2012 10:27 AM

systemd, running scripts after suspend/hibernate
 
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

Heiko Baums 10-02-2012 11:28 AM

systemd, running scripts after suspend/hibernate
 
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

Heiko Baums 10-02-2012 11:36 AM

systemd, running scripts after suspend/hibernate
 
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

Thomas Bächler 10-02-2012 11:47 AM

systemd, running scripts after suspend/hibernate
 
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.

Tom Gundersen 10-02-2012 12:03 PM

systemd, running scripts after suspend/hibernate
 
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

Brandon Watkins 10-02-2012 01:44 PM

systemd, running scripts after suspend/hibernate
 
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.

Jakob Herrmann 10-03-2012 01:48 AM

systemd, running scripts after suspend/hibernate
 
-----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/

iQIbBAEBAgAGBQJQa5mJAAoJEOl7hkDId7Ymj9oP93zmL9miaU fhve5aMq2HDA6v
wqMkaSKDAN/TZZJhYklJQUkWl7BMV7nIJVGYVlGAG1jWCW6MPF8X5jS/UF10pKm4
Z1tabeP3BcJbDSSE9TMoeE1+9lnM3bhhHGBKJqs8iq+0V6XpeL T6cojnnvaFUEDa
p+f3VHFNlXNInFvGwdk+X5BYubnaIEYAH0HTQPJ6Fq7I9KQtpf EjgRuA8w1vVv55
9Cx6mZjn0Kz0FpfcP0MN9QMkmNCFwWAR+A35Gzx57GoyMhwY21 aJLsywpxd4KWPR
kyOp6FGJxaZ1jN6Ob0iAmfOhSG9Mw4ckt6oeK7NHur01wrvlOB 9RsqhgG8+CtfMN
H6gokrU9NG7zBdSmNsCZBPDJPGX1pZr+YxfcE7dEznq3ljqX/3BmjsScakXvwDsE
UEjfaMpJH+YsZ71H/7BiPUVulzEeO/PZ2izg+PGtDPgIHAAZLNqQge44RJ/V4S/5
DYrqTIC5xyJ/dkdcftiuc1Got/KUSqqEfoZ8MNlVKdaxMVP8VcLkbpbL2PRoxi0D
puO+TNGSOCtJl3gQdi8X1PsD9DP5vBoV/mFUmAHSmybGbUtj2v1IklvsWXNAPtDX
x3dIgNXaklFdLivxPd5OwxN4kGqZ8hBDx/49BaHjU21Rx1pk3pgZ4mO4HxuZ3D8s
Y27VsR5tKeGEfP3RZSw=
=KRMI
-----END PGP SIGNATURE-----


All times are GMT. The time now is 05:20 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.