S6-SOCKET-ACTIVATION(7)

💖 NAME 💖

okay bestie, this is s6-socket-activation — the performing socket activation with s6 page, from the Miscellaneous Information Manual, aka S6-SOCKET-ACTIVATION(7). iykyk ✨

---

🌸 DESCRIPTION 🌸

First thing first, bestie: it is 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)

---

Debian 🎀 April 16, 2024 — and that's the whole page, bestie, no cap. 💖✨