S6-SVSCAN-NOT-AS-PROCESS-1(7)

πŸ“¦ version 2.15.1.0, in nixpkgs unstable

πŸ’… S6-SVSCAN-NOT-AS-PROCESS-1(7) πŸ’…

okay bestie, so this one lives in the Miscellaneous Information Manual, and it's all about running s6-svscan(8) under another init process. yes, you heard me. you don't have to go full process-1 mode. let's get into it 🫢


✨ NAME ✨

s6-svscan-not-as-process-1 β€” running s6-svscan(8) under another init process. that's the whole vibe. no cap.


🌸 DESCRIPTION 🌸

you can have a reliable supervision tree even if s6-svscan(8) is not your process 1. literally so valid of you.

but here's the catch, and it's kind of the whole point: the supervision tree just has to be rooted in process 1. meaning your process 1 has to supervise your s6-svscan(8) process somehow. that's the assignment. that way, if s6-svscan(8) dies, it gets restarted, and your set of services is always maintained. always. maintained. periodt. πŸ‘‘

⚠️ be aware though, bestie, because this part matters: pipes between services and loggers are maintained by the s6-svscan(8) process. if this process dies, the pipes will be closed and some logs may be lost. 😭 not a vibe. plan accordingly.

πŸŽ€ Logging the supervision tree's output πŸŽ€

so s6-svscan(8) and the various s6-supervise(8) processes might produce error or warning messages. those messages get written to s6-svscan(8)'s stderr (which is inherited by the s6-supervise(8) processes). and you're gonna want to log these messages. here's how:

  • you can use your init system's logging tools, and make your init system launch s6-svscan(8) as is β€” its stderr should already be taken care of by the logging tools. easy. iconic. ✨
  • you can use a trick similar to the s6-svscan-as-process-1(7) process 1 output logging trick, so the supervision tree's messages are logged via a service that's maintained by the supervision tree itself. cute, right? in that case, your init system should not launch s6-svscan(8) directly, but a wrapper script that performs the proper redirections. the examples/s6-svscanboot file in the s6 distribution gives an example of such a script. and make sure your initial s6-scan-directory(7) contains an s6-service-directory(7) for your initial logging service, that must read on the logging FIFO. don't skip that part, i'm serious 🫢

in some of the following examples, we'll assume that /command/s6-svscanboot is the name of the script you're using to start s6-svscan(8). we'll also assume that all of the s6 executables are available through the /command path. adjust this accordingly β€” i trust you πŸ’–

🌈 System V init 🌈

put an appropriate line in your /etc/inittab file, then reload this config file with telinit q:

SV:123456:respawn:/command/s6-svscanboot

that's it. slay.

πŸ¦‹ Upstart πŸ¦‹

put an appropriate configuration file in the /etc/init folder, for instance /etc/init/s6-svscan.conf, then start the service with start s6-svscan:

# s6-svscan
start on runlevel [2345]
stop on runlevel [!2345]

oom never
respawn
exec /command/s6-svscanboot

chef's kiss. πŸ’…

πŸ”₯ systemd πŸ”₯

put an appropriate unit file in the /etc/systemd/system folder, for instance /etc/systemd/system/s6.service. it will be picked up by systemd at boot time:

[Unit]
Description=s6 supervision tree
Documentation=https://skarnet.org/software/s6/

[Install]
WantedBy=multi-user.target

[Service]
Type=simple
ExecStart=/command/s6-svscan /run/service
ExecReload=/command/s6-svscanctl -an /run/service
Restart=always
RestartSec=1
KillMode=mixed

now, please note β€” among other things, systemd performs process supervision, so depending on the level of integration with your distribution that you wish to achieve, you may be better off using systemd to directly manage your daemons. that's the polite version.

and please also note that systemd is a terrible piece of software engineering[1], and if at all possible, you should try and switch to a distribution that does not use it. πŸ’€ i said what i said. (lovingly. but also fr fr.)

πŸ’œ BSD init πŸ’œ

put an appropriate line in your /etc/ttys file, then reload this file with kill -s HUP 1:

sv /command/s6-svscanboot "" on

clean, simple, we love to see it. πŸŽ€

πŸ“ MacOS launchd πŸ“

like systemd, launchd comes with its own way of supervising services[2]; if you are a launchd user, you probably do not need s6. no shade, it's just not your era bestie πŸ™ˆ


⭐ SEE ALSO ⭐


πŸ‘‘ AUTHORS πŸ‘‘

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

and that's the whole page, bestie πŸ’– this cutie shipped with Debian, dated November 21, 2023 β€” so go forth, root that supervision tree in process 1, and keep your services maintained. mwah. 🌸🧚✨

πŸ“¦ where this page comes from