On 2015-12-25 13:11, Casper Ti. Vector wrote:
> * s6-ipcserver was moved from s6-networking to s6, but
> `s6:doc/ucspilogd.html' still refers to `s6-ipcserver' with a link to
> <http://skarnet.org/software/s6-networking/s6-ipcserver.html>;
> similarly, `s6:doc/s6-log.html' talks about "combined with the
> s6-networking package".
Fixed, thanks.
> * s6, s6-rc and s6-networking use execline's library, which is itself
> undocumented; perhaps it will also be documented?
I should do it at some point indeed. Initially execline was only meant
to be a set of command-line tools, and the library primitives weren't meant
to be exported, that's why I didn't document them. But progressively, I
found myself relying more and more on various library entry points, which
led to the current situation.
I'm reluctant to document all of it. Pieces of the execline library are
hackish, or I'm not entirely satisfied with the syntax, and I want to have
the freedom to change the interfaces if I come up with something better.
But some important functions, such as el_parse() - which is probably what
most people would be interested in - are stable enough to be documented,
yes.
> * The fd holder in s6 seem unable to retain its state over restart,
> which IMHO can be a small SPOF. Not serious, but not always
> insignificant (see <https://stackoverflow.com/questions/2580933> for
> an example).
Yeah, well, that's the nature of a fd-holder. You can only hold fds in a
living process; there's just no other possible storage for it. So, if a
cosmic ray kills the process, tough luck. A cosmic ray may also hit your
process 1, or your kernel, in which case your whole machine is borked and
there's not much you can do about it.
But as usual, if you want more reliability, just add more resources. If
you fear a single fd-holder will be a SPOF, make two! Have the primary
dump its state to a secondary, and mirror changes. If five nines aren't
good enough for you, you can get ten nines for the price of one more
s6-fdholderd process and some scripting. All the tools are there: for
instance, s6-fdholder-transferdump for the initial copy.
> Also, if persistence is to be implemented (eg. through
> some FIFO files), a specified way to clear the persistent store might
> also be useful.
There's really no other way to keep fds open than to have living processes
keeping them open. If relying on one process staying alive is too risky for
you, keep two. Or three. Or as many as you want: s6-fdholderd is pretty small.
Note that s6-svscan acts as a fdholder for the pipes between services
and loggers. And systemd acts as a fdholder for every socket registered with
it. The mechanism is reliable; protect your fd-holders against OOM-killers,
run them under specific uids, and you'll be fine.
--
Laurent
Received on Fri Dec 25 2015 - 19:52:04 UTC