[kwlug-disc] Inconsistency in systemd ...

[Ronald Barnes]

Khalid Baheyeldin wrote on 2017-05-26 05:13 PM:

> Yes, this is another systemd rant ...
>
> As many of you know, most distros have been adding more and more
> systemd integration with their new releases.

True.  This bothered me.  Until I realized Arch Linux adopted it.  And
judging from their wiki, they know what they're doing (it seems to me).



> Here is the use case: When I put the laptop to sleep, I want to
> unmount the remote file systems [snip]
>
> But in Ubuntu 16.04 and its variants, this no longer works. Why?
> Because systemd decided that this is not the right way to do things,
> and instead the script has to be in /lib/systemd/system-sleep/.

From
https://www.freedesktop.org/software/systemd/man/systemd-suspend.service.html
is this:

> Note that scripts or binaries dropped in
> /usr/lib/systemd/system-sleep/ are intended for local use only and
> should be considered hacks. If applications want to react to system
> suspend/hibernation and resume, they should rather use the Inhibitor
> interface.

Have a look at that, and the Inhibitor interface: prevents sleep midway 
through burning an optical drive, for example.


>
> WHAT? A SCRIPT you say? You mean A SHELL SCRIPT? Wasn't the whole
> rationale of systemd is to not write scripts because SCRIPTS ARE BAD,
> and use unit file directives?

 From a quick search, it seems unit files are the recommended way:

> https://wiki.archlinux.org/index.php/Power_management#Power_management_with_systemd

>
>
> Suspend and hibernate
>
> systemd provides commands for suspend to RAM, hibernate and a hybrid
> suspend using the kernel's native suspend/resume functionality. There
> are also mechanisms to add hooks to customize pre- and post-suspend
> actions. Note: systemd can also use other suspend backends (such as
> Uswsusp or TuxOnIce), in addition to the default kernel backend, in
> order to put the computer to sleep or hibernate. See Uswsusp#With
> systemd for an example.
>
> systemctl suspend should work out of the box, for systemctl
> hibernate to work on your system you need to follow the instructions
> at Suspend and hibernate#Hibernation.

It does appear that one can hook in to the suspend sequence.




> WHAT? So NO ORDER OF EXECUTION? NO DEPENDENCIES and before/after
> order? Wasn't these the rationale for systemd in the first place?
> There is no way to specify order of execution, or prerequisites.

 From Arch wiki:

> /etc/systemd/system/suspend at .service
>
> [Unit] Description=User suspend actions Before=sleep.target

and

> /etc/systemd/system/resume at .service
>
> [Unit] Description=User resume actions After=suspend.target



> The systemd developers contradicted themselves here, twice.

Have a look at the unit files, that's their recommendation and it seems
to work okay.


> And there are annoying side effects too. Sometimes, the Network
> Widget in the notification area will be lost, and instead of a WiFi
> icon, it would show the up/down arrow icon, and clicking on it will
> not show the current connection, or other Wifi access points
> available. This is probably because wpa_supplicant died or
> something.

That's annoying.  Try: systemctl restart network-manager.service


Keep us posted on your progress; be happy to hear this works or willing
to try to get it working.


Regards,

rb