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. --- Makefile | 3 +++ systemd/netcfg-suspend.service | 10 ++++++++++ 2 files changed, 13 insertions(+) create mode 100644 systemd/netcfg-suspend.service
diff --git a/Makefile b/Makefile index bbada3f..1396820 100644 --- a/Makefile +++ b/Makefile @@ -38,6 +38,9 @@ install: install-docs install -m644 \ systemd/*.service \ $(DESTDIR)/usr/lib/systemd/system/ + install -d $(DESTDIR)/usr/lib/systemd/system/sleep.target.wants + ln -s ../netcfg-suspend.service \ + $(DESTDIR)/usr/lib/systemd/sleep.target.wants
install-docs: docs install -d $(DESTDIR)/usr/share/man/{man5,man8} 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
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.
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?
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
arch-projects@lists.archlinux.org