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
Received on Mon Jul 13 2015 - 09:00:20 UTC