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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel