[systemd-devel] systemd's interfaces are a bit wonky

[Steven Stewart-Gallus]

Hello, I am making my own little init system for my game in order to
sandbox and monitor individual child programs in it.  I plan on
reusing systemd's unit file format and other conventions instead of
inventing my own.  I know that the systemd developers would like to
have a good set of common and portable interfaces for system
management and I have found a few wonky bits that maybe the systemd
developers would like to improve and that the systemd developers might
be able to give me advice on implementing.

First, about systemd's LISTEN_PID environment variable convention.

This convention is annoying because for my init system it prevents one
from temporarily substituting in an invocation of strace instead of a
program (LISTEN_PID will refer to the strace process and not the child
running under it).  I don't think there's a way to substitute in
strace transparently with this convention.

As well, LISTEN_PID is impossible to implement on machines that do not
support fork like Windows, or certain embedded platforms.  At any
rate, even if a platform does support fork (like Cygwin) it might be
slow or hacky and unstable.  Moreover, using fork properly is fraught
with difficulties in a multithreaded program because then one has to
only use async-signal-safe functions.  I have to use fork on Linux
anyways to implement certain sandboxing features but requiring fork
for implementors of this interface in general still seems kind of
wonky to me.  I'm not sure how I'll adapt the LISTEN_PID convention to
work on Windows when I port there.

Second, systemd's unit file syntax is a bit ugly to parse.  I would
like to parse a unit file as a simple hash table of hash tables of
strings.  However, systemd's unit file syntax has the catch that
"[some options] may be specified more than once, in which case the
specified list of [stuff] is merged. If the empty string is assigned
to this option, the list is reset and all prior assignments will have
no effect."  Now I can't treat unit files as simply as I would like if
I wish to support the full syntax of systemd's unit files.  So, I
probably won't support the full extent of the syntax because it's
annoying and I don't need to anyways.  I just thought that systemd
developers might know of an easy way to solve this problem and also
might want to know that that people are going to avoid or struggle
with implementing this part of the interface of systemd's unit files.

Third, systemd's notification interface doesn't work well with hard
real-time and safety critical environments.  Writing to a socket
potentially allocates memory and can take an unknowable amount of
time.  Even for hard real-time and safety critical environments this
is probably not a real problem as notifications are mostly just debug
information.  However, sd_notify(ERRNO=...) and sd_notify(WATCHDOG=1)
are important interfaces and should be doable even in critical
situations.  Personally, I don't need hard real-time or
safety-critical requirements (I'm only writing a game, remember) but
it just bugs me that I need to rely upon memory allocations for these
interfaces which of course can fail at any time.  These aren't real
problems as people can just create extensions for their needs but they
are minor annoyances that the systemd developers might want to be
aware of.