26.04.2019, 01:10, "Laurent Bercot" <ska-supervis...@skarnet.org>: > The bad news is that the way daemontools-encore's svscan manages > its catch-all logger is almost exactly the way I do it in my stage 1 > scripts, except it requires ad-hoc code in svscan.
but this "ad-hoc code" is in C and does not require any execline tricks. for those to work you need execline installed too. that way daemontools-encore's svscan can easily get directly started and supervised by process #1 without any effort. i think this feature does not require too much "ad-hoc" C code in the svscan source. it is easy to do that in C while it becomes hard to impossible do write a shell script that does it (ok, in execline this seems to be possible, but you need that package installed then). > Additionally, the way daemontools-encore does it, the logdir may > or may not be in the scandir. really ? i always used a service subdir of the scandir and it worked very well. > If it is not in the scandir, it will > not be watched by svscan, and if both the supervise process and the > logger die, nothing will ever read the logpipe again and when the > kernel buffer fills up, your supervision tree will eventually freeze. pretty artificial counter example since noone will use a service dir outside the scandir. i do not know if this is even possible ... in any case doing so seems very odd to me and was probably not intended by the author. > and performing a little FIFO trickery at svscan start time in order see ? "a little trickery" is necessary here. > to redirect its stdout and stderr to a FIFO (that the catch-all > logger will read from). The differences in implementation is that > the logpipe is a FIFO, not an anonymous pipe, and it's held open by > the logger, not by svscan or supervise. using a fifo here is IMO not the best solution when using a simple pipe(2) would suffice since fifos need read-write access to fs they reside on. > You're saying that my implementation makes running s6-svscan under > sysvinit complex because you need 2 lines in /etc/inittab. that was just a general remark not specific to SysV, busybox or toybox init that applies to every process #1 (and also to init stage 1 when using s6-svscan as stage 2) > That is not true: you only need 1 inittab line, that runs a "mini-stage 1" > script that performs the FIFO trick (as well as any other early > preparation that you need) before executing s6-svscan. yes that works but introduces an extra step of indirection. and again this seems to require execline. it becomes more difficult doing so directly from -say- inittab or its actual equivalent for the given init system. > You're also saying that this implementation makes stage 1 scripts > difficult to write. That is true indeed. > I would also recommend you, or anyone interested in stage 1 script > creation, to do this sooner rather than later, because a new version > of s6-linux-init is going to be released in less than a week, i see. > and it will be significantly different, and more complex > (because more featureful, > with a focus on turnkey sysvinit compatibility who needs such compatibility anyway ? those who want/need it should run SysV init directly and start s6 per init script/inittab entry. > stage 1 will be a C program rather than an execline script nice ! that sounds really interesting to me. you have suprised and teased me definitely with this announcement. good luck.