On 12/07/2015 23:26, Guillermo wrote:
* Compatibility. For s6, I believe it was mentioned somewhere that it is tested at least on FreeBSD, OpenBSD and Solaris.
Also NetBSD and Darwin (MacOS X). As for AIX and other OSes, the important question is: do they provide an implementation of getpeereid() or equivalent functionality ? If yes, then there's no theoretical objection to making it work on them too, I just haven't done the research for OS-specific quirks or registered an account on those systems for testing.
the execline scripts produced by s6-linux-init-maker (from the s6-linux-init package) that help getting s6-svscan to run as process 1 are Linux-specific.
Yes. The s6-linux-init package itself is portable: the s6-linux-init-maker tool will run on any of the above OSes. However, the scripts it produces are Linux-specific, because they use Linux-specific tools, for instance to mount a tmpfs, or reboot the system. There is no obstacle to porting s6-linux-init to other OSes; it's just more OS-specific work. I may do it if there's demand. But anyone savvy enough in BSD, for instance, can look at the output of s6-linux-init-maker and convert the scripts to something that works with BSD.
* The row containing readproctitle. It could be renamed to "supervision tree log handling" or something like that, and may fit better in section "Logging". The entries for s6 and nosh could be "catch-all logger (s6-svscan-log)", again from the s6-linux-init package, and "catch-all logger (cyclog)", respectively. The catch-all logger being a supervised long-lived process that receives and logs (to a log directory) all output from the supervision tree, including the one from processes that do not have a dedicated logger.
Note that the idea of a catch-all logger isn't specific to Linux or anything; it will work on any OS, and it's possible to implement it manually, following the steps outlined in the s6-log documentation. The s6-linux-init package simply automates the creation of scripts implementing a catch-all logger.
* Supervisor Programs. For nosh, the program similar to svscan would be service-dt-scanner, in the sense that it runs on a scan directory. Footnote 2 would apply (only to service-dt-scanner), since it can also be called as svscan. The program similar to supervise would be service-manager, in the sense that supervised processes run as its children, and it will restart them if they exit or crash (and if the "restart" file in their respective service directory says so).
And for perp, the perpd program is the whole supervision tree, i.e. it has both "svscan" and "supervise" functionality. "svscanboot" isn't a supervisor program. It's a script that starts a supervision tree. For daemontools, it kinda makes sense, because the official way of logging the supervision tree's output is readproctitle, so providing an official script to start things in the official way is logical. For other supervision suites, there's no official way of starting the supervision tree with a logger. You just adjust your file descriptors beforehand, then start the scanner directly. Even runit does it that way: the stage 2 script is a normal init script that happens to launch runsvdir, but you can do whatever you want in the stage 2 script.
* Force a service to stay in the same process group. I haven't used daemontools[-encore] or runit, but looking at their source code, pgrphack and chpst -P use the setsid() system call, so this row should rather be "create a new session and make the service the session leader", and the entries for s6 and nosh would be s6-setsid and setsid, respectively.
Yes, you can't force a service to stay in the same process group - what you can do is make it a session leader, and further calls to setsid() will fail. There's generally no use for the pgrphack/s6-setsid family of tools. The mistake of auto-backgrounding is common, so the fghack family of tools has easily identifiable uses, and it *is* a hack all right; but I've never seen a daemon misuse sessions and process groups, probably because those are one of the hairiest parts of Unix, and the least you hear about them, the better off you are. :) That's why I named s6-setsid as it is named: it's not a hack, it has rare but useful legit uses. It's unlikely you'll find such legit uses in a run script, however. -- Laurent
