Restart a snap background service on resume from suspend

I have a snap that needs to be restarted when system resumed back from suspend, because at the start of that process, it notifies clients on the local WiFi network using zeroconf that “we are ready to rock”.

How do I tell my snap to restart when resumed from suspend ?

Below is the yaml file, in case its of any help https://github.com/deskconn/deskconn-server/blob/master/snap/snapcraft.yaml

The other option could be, to listen to network states i.e. when a network interface (eth*, wl* and others) gets connected/disconnected and run my code as a result. I still need to find a python library that does that though.

Bumping this one as it may have got lost in the holidays

I don’t think there is currently any way to do this for a snap. Does anybody know if there a systemd directive that does this? Ping @mborzecki

I think snapd could gain some ability to add something like After=suspend.target, but I don’t know what how best to enumerate that in the snap.yaml. Maybe something with restart-condition: resume?

I’m not aware of any systemd directive that would do that. I looked at suspend.target, but it’s not clear whether adding After=suspend.target does the right thing.

However, logind sends a signal over DBus when the system is going into sleep and another one when the system resumes. There’s some documentation right here: https://www.freedesktop.org/wiki/Software/systemd/inhibit/. Receiving the signals is already covered by upower-observe interface.

@om26er On a side note, I think the service should actually act on network interface state changes, specifically when UPnP is involved. You should be able to register the service with avahi and let it handle the rest.

If you’re looking for examples, this is something I wrote a longer while ago: https://github.com/open-rnd/ros3d-stream/blob/master/src/zeroconf.vala It’s in Vala, but executes Avahi bindings. It should be possible to do the same with Python using GObject introspection bindings.

Spent some time experimenting with systemd and discussing this with @chipaca. For future reference: https://github.com/systemd/systemd/issues/6364 has some useful information.