I wish I could make friends with systemd like y'all. I spent at least
a week wrestling unsuccessfully with systemd (admittedly starting from
complete ignorance) to make a service that
synchronizes a local directory on a laptop with a remote directory on
a server after a docker container is stopped but before the
filesystems and network stack are torn down during poweroff. It was
easy enough to accomplish by manually invoking a script prior to
powering off but no amount of cajoling, poring over documentation, or
reading and adapting examples from forum posts on my part would get
systemd to do it automatically without conflicts, race
conditions, or timeouts. Is this not exactly the kind of problem systemd
dependences are intended to solve?
Comments
I wish I could make friends with systemd like y'all. I spent at least a week wrestling unsuccessfully with systemd (admittedly starting from complete ignorance) to make a service that synchronizes a local directory on a laptop with a remote directory on a server after a docker container is stopped but before the filesystems and network stack are torn down during poweroff. It was easy enough to accomplish by manually invoking a script prior to powering off but no amount of cajoling, poring over documentation, or reading and adapting examples from forum posts on my part would get systemd to do it automatically without conflicts, race conditions, or timeouts. Is this not exactly the kind of problem systemd dependences are intended to solve?
Docker and systemd aren't exactly good friends, this is partially why Red Hat created Podman.
Podmans integration with systemd is much greater, especially when you use quadlets (systemd controlled podman containers).
Naively, I'd expect `ExecStop=` to just work™. Is this not the case?
The issue would be blocking the network coming down.
I think something like:
Yeah it’s definitely expressable but non-obvious