S6-SOCKET-ACTIVATION(7)

NAME
s6-socket-activation - performing socket activation with s6

DESCRIPTION
First, it's important to realize that you don't need socket activation. It's a marketing word used by systemd advocates that mixes a couple useful architecture concepts and several horrible ideas, for a very minor speed benefit. Read [1] and [2] for details.

•   s6 will not help you implement super-servers in process 1, because doing so is bad engineering. However, it will help you set up super-servers. The s6-ipcserver(8) program, for Unix domain sockets, as well as the s6-tcpserver(8) program, for TCP INET domain sockets ( available in the s6-networking package[3]) are super-servers you can use to your heart's content. They are even wrappers around simpler programs, and you can use their components in the way you choose: bind sockets, drop privileges, accept connections from clients, it's all about what you write in your command line. Super-servers are a good thing; using process 1 to act as a super-server is not. s6 provides you with the tools to get the good without the bad.

•   s6 will not help you run all your services before their dependencies are met, because doing so is very bad engineering. However, it will provide you with:

    •   a reliable logging infrastructure, that makes sure your services never lose logs: s6-log(8), in conjunction with s6-supervise(8) and s6-svscan(8).

    •   ways to open your sockets and bind them as early as you want in your boot process, and make them accept client connections later: s6-ipcserver-socketbinder(8), s6-tcpserver-socketbinder(8).

    •   a supervision infrastructure that can start as many services in parallel as you want: s6-supervise(8) and s6-svscan(8).

•   s6 will not help you centralize all your socket information in process 1, because doing so is contrary to modularity and independence of services. However, s6 will provide you with a way to store your open sockets and retrieve them when you want, which it calls “fd holding”: s6-fdholder-daemon(8).

  So, how do I open all my sockets first, store them, and dispatch them to daemons later?
Again, it's not necessary to do that: you'll be fine, and quite speedy, just starting your daemons in their good time. You will not reap any noticeable benefit from performing “socket activation”. But if you really want to:

1.  Make sure you have an early supervision infrastructure running. Ideally, you would make s6-svscan(8) your process 1 .

2.  Start an early fd-holding service, e.g. s6-fdholder-daemon(8). Let's say the fd-holding daemon is listening on socket /service/fdholder/s.

3.  For every Unix domain socket /my/socket you need to open, run:

        s6-ipcserver-socketbinder /my/socket s6-fdholder-store /service/fdholder/s unix:/my/socket

    You can do the same with INET domain sockets.

4.  Proceed to your initialization.

5.  When you want to run a daemon ‘myserverd’ that accepts clients connecting to /my/socket, run:

        s6-fdholder-retrieve /service/fdholder/s unix:/my/socket myserverd

    ‘myserverd’ will be executed with /my/socket as its standard input.

6.  The descriptors remain safely stored in the fd-holding daemon and you can retrieve them again whenever you want, for instance when your service crashes and is restarted.

That is all there is to it. You don't have to use specific libraries or write complex unit files, you just need to understand how a command line works. This is Unix.

SEE ALSO
[1] https://skarnet.org/lists/supervision/0422.html

[2] https://forums.gentoo.org/viewtopic-t-994548-postdays-0-postorder-asc-start-25.html#7581522

[3] https://skarnet.org/software/s6-networking/

AUTHORS
Laurent Bercot Alexis <flexibeast@gmail.com> (man page port)