#systemd #linux #kludge
I have no one else who will find this interesting so might as well yell it out into the ether.
You can create a hacky mutex in systemd to prevent units from starting if there is an extant unit that "holds" the mutex.
Why would you do this? Well, I needed to run a process in a very specific network namespace and running it via a container within that context was a royal pain.
I got a python service running which would receive request via websocket or HTTP and spawn a systemd transient unit which would survive the python service dying or being restarted. Awesome!
Then a few months later, I get the idea of a web UI and realize that dbus is slow if you are trying to poke it for properties for every unit in the `foo@*.service` glob-space.
I really only needed a start timestamp from systemd and the python service could remain gloriously stateless. Lets say that at this point, it was less about what's good and more about getting it to work as I wanted it. I wanted to be able to just list all the systemd units and derive the frontend from that.
So I ended up configuring the systemd transient unit to be named `foo@$id-$startTime.service` and I set two properties, `Type=exec` and `BusName=$id`.
Now systemd supports notification via dbus as an exec type, it also can grab the dbus bus interface name for a service and hold it so no one else can grab it. But if you just use `BusName=` then systemd will wait for the unit until it actually notifies dbus. Which cool, but I'm running ffmpeg!
Then I just tried `Type=exec` and `BusName=$id` and it worked! I could stick both $id and $startTime into the unit name *and* have any subsequent units fail to launch because they couldn't grab the dbus bus interface name (because the first one grabbed it).
What's super nice is that since the units transient, when it finishes or fails, it'll be GC'd and the BusName will be freed.
Thank you for coming to my talk. 😅

