Re: emergency IPC with SysV message queues

[Jeff <sysinit@yandex.com>]

> What details need to be conveyed other than "stand up", "sit down",
> and "roll over" (boot, sigpwr, sigint)?

depends on what you plan to do. for a minimal init handling SIGCHLD
(that is an interesting point indeed. is it really necessary ?
i still have to find out. would be nice if one could run without it
though.) and (Linux) SIG(INT,WINCH) should be sufficient.
in the case of the latter 2 it would be enough to run an external
executable to notify their arrival and let the admin decide what
to do about them. maybe SIGPWR is of relevance too.
that suffices for init itself.

a supervisor needs more information, such as:
start this service, stop that one, disable another, restart one,
signal another one and so on, depends on what capabilities the
supervisor provides.

and this has to be encoded in such a protocol that uses 2 ipc
mechanisms: sysv ipc and a specific signal (SIGIO comes to mind)
to notify the daemon (maybe a third one: (abstract) sockets).

> Abstract namespace sockets have two shortcomings:
>
> * not portable beyond linux

true, but i would use them where available and standard unix sockets
elsewhere.

> * need to use access restrictions

don't you use credentials anyway ?
AFAIK all the BSDs and Solaris have them too.

> * shared across different mount namespaces;
>   one needs a new network namespace for different instances

so you need to care for that namespaces too. this can be an
advantage since it is decoupled from mount namespaces though.

i did not consider namespaces at all since i follow the systemd
development approach: works on my laptop, hence works everywhere. :-(

> I am considering dropping it for a socket in /run in my supervisor.

why not ? i would use standard unix sockets for everything with
PID > 1 too, but in the process #1 situation i guess they provide
an advantage.