[arch-projects] [netcfg] [PATCH] systemd: suspend profiles upon sleep (as in pm-utils)

Ivan Shapovalov intelfx100 at gmail.com
Tue Nov 6 02:48:49 EST 2012


On 25 October 2012 21:20:20 Thomas Bächler wrote:
> Am 25.10.2012 20:45, schrieb Ivan Shapovalov:
> > Add a unit file and statically install it to sleep.target.wants
> > since "netcfg all-suspend" / "netcfg all-resume" are no-ops when no
> > netcfg profiles are activated so they are safe to invoke every time.
> > ---
> > diff --git a/systemd/netcfg-suspend.service
> > b/systemd/netcfg-suspend.service new file mode 100644
> > index 0000000..c4ad1a9
> > --- /dev/null
> > +++ b/systemd/netcfg-suspend.service
> > @@ -0,0 +1,10 @@
> > +[Unit]
> > +Description=Suspend netcfg profiles upon sleep
> > +PartOf=sleep.target
> > +
> > +[Service]
> > +Type=oneshot
> > +RemainAfterExit=yes
> > +ExecStart=/usr/bin/netcfg all-suspend
> > +ExecStop=/usr/bin/netcfg all-resume
> > +KillMode=none
> 
> I don't like this at all. When you have a profile that runs processes
> (wpa_supplicant, dhcp client), they run within the correct systemd unit
> that belongs to the profile.
> 
> With this unit, after suspend, the processes will belong to the unit of
> the suspend service. This removes all the knowledge that systemd has
> over which processes belong to which service.

> 
> As witnessed by my patches yesterday, I am currently in the process of
> trying to make systemd integration of netcfg better, this is clearly a
> step back.

Yes, you are right here...

> 
> I am unsure how systemd's sleep target works, but wouldn't it be a
> matter of simply having Conflicts=sleep.target in the systemd units to
> make this work right?

It's not so simple.
1) "Conflicts=" is one-directional: it does not restart stopped units.
2) This will not have any effect on profiles started with "netcfg <profile>" 
instead of "systemctl start netcfg-profile-<profile>.service".

- Ivan


More information about the arch-projects mailing list