Hi Michael -
Thanks for the attempt to remedy.
My problem is I start my VPN (openvpn) from /etc/rc.local, from
/etc/acpi/actions/lm_lid.sh, and from su under a regular user shell
(getty -> bash -> xinit -> rxvt -> bash -> su), depending on the
situation. I have used the same shell script for this task since 2003 on
Debian and MacOS.
In order to get my umount to occur before systemd kills openvpn, I must
decipher the ordering of service shutdowns defined by After relations.
The answer to this core question should be trivial.
The documentation provides one simple rule, which, if it was true, would
be the sensible foundation of a system management daemon: if unit x has
"After=y", then x.ExecStart comes after y.ExecStart, and y.ExecStop comes
after x.ExecStop.
Except:
* That relationship changes based on whether there is a Requires or
Wants relationship between x and y. Very important, and UNDOCUMENTED!
* Does Type (forking, oneshot, etc) affect the ordering? UNDOCUMENTED.
* Do targets, scopes, slices, and services all honor these orderings in
the same way? No idea - but the documentation does say implicit
After rules abound, all very special-cased. Not amenable to
straightforward analysis from axioms.
* Why doesn't "After=getty.target" cause my unit's ExecStop script to
run before my interactive shells are killed, given they all derive
from getty? I don't know why but "systemctl status" says the shells
are owned by session-c1.scope.
* What is session-c1.scope? It is dynamically-generated, HARD-CODED,
OPAQUE, UNDOCUMENTED.
These are a few of the things you must tackle before you can run a script
before interactive shells are killed. In the old way of doing things,
you could grep around /etc for the killall5 invocation and you'd have a
pretty complete picture of what's going on in a matter of minutes.
The resolution I came up with is for openvpn to run under its own
specific systemd service, which I made and manage explicitly. First,
it's bad because systemd forced me to learn its idioms rather than
playing well with others. Second, it's bad, because systemd's idioms are
magical instead of simple. I was forced to learn something stupid.
I know, and I think you know, that systemd will change before I get to
use this knowledge again.
How much simplicity are we going to sacrifice to gnome's quixotic quest
to win the battle for the desktop?
Yuck.
Catch you on the flip side,
- Greg
