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