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

[Lennart Poettering]

On Mon, 25.08.14 22:27, Steven Stewart-Gallus (sstewartgallus00 at mylangara.bc.ca) wrote:

> 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

"common and portable"? I don't think that the systemd unit file format
makes much sense outside of the systemd context. The dependency logic
requires a full state engine to be available, and if you rewrite that
you have rewrite all of systemd really. If you want something like
systemd, use systemd. 

> 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.

strace -D

> As well, LISTEN_PID is impossible to implement on machines that do not
> support fork like Windows, or certain embedded platforms.  

systemd only runs on Linux. And is not intended to be portable on other
operating systems.

Also, I am pretty sure PIDs are more commonly supported than file
descriptors. Or to turn this around if you have Unix-compatible fds,
then you have Unix-compatible PIDs too. But again, this discussion is
moot.

The $LISTEN_PID logic we added in order to ensure that we don't confused
binaries down the tree if $LISTEN_FDS doesn't get reset by a
process. 

> 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.

Hmm? On Unix you start new processes with fork()/clone(), there's no way
around it.

> 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.

Hmm? The multiple-assignment syntax not only exists because it makes
things more readable, but also do make extension of existing unit files
via .d/ drop-ins workable.

> 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.

Hmm? Linux is not a hard realtime system. And yeah, we use dynamic
memory, of course we do. And so does the kernel, and everything else in
the stack. And this is the only thing that makes sense.

Lennart

-- 
Lennart Poettering, Red Hat