Further trivia: Going one level up from busybox, the maintainer of dash is the creator of runit. Both runit and s6 are "inspired by" djb's daemontools. In truth, neither [wc]ould have been created if not for daemontools.

Oh, interesting! Anybody used s6? I like the theory, but for me what matters is mainly the practice.

Used s6-overlay[1] to start a lot daemons in a docker-image for demo purposes - postgres, tomcat, mysql, php-fpm, apache (don't ask why ;) - s6 worked really well and was reliable and stable - I enjoyed it very much. It was also possible to reliable pass SIGTERM to the daemons in the image for clean shutdown and it was easily possible to configure logging to stdout with a prefix. Modelling dependencies (waiting on database before starting app etc.pp) is possible via shell-scripts. It's super flexible but out of the box it's more like a collection of powerful tools not a complete package - but that's good. It's in the tradition of djb daemontools and is very unix - as in doesn't talk a lot and you better know how each part works but - and that's really cool - it's modular and simple and once you get a grip on it you can easily reason about it. systemd takes a completely different approach and also solves a kind of differnt problem - this is like small pieces of lego that compose well instead of one big chunk of glib/dbus/glibc only c-code.

1: https://github.com/just-containers/s6-overlay

We do - and have found it very reliable and I really like it :-)

One of the members of our team finds it more complex when it comes to diagnosing why things aren't running/starting as expected, but that's also down to the complexity we have around s6 with other setup scripts (we use it to manage the full suite of processes in our product).

Hence, they're not the biggest fan of it (and would talk negatively about it), but I _think_ s6 isn't really the culprit and instead the other complexity is.

Although, when things go wrong it can be a little bit harder to chase down than it was with our former manual "start this process" type scripts... But, you can just `./run` the run script which may tell you enough :-)

Thanks! That makes sense to me. Personally, I usually like tools and practices that can feel rough when there's too much complexity. When there are problems, I think it's generally good that people feel like there are problems.

linuxserver.io uses s6-overlay for all their images, which are very popular in the self-hosting community.

They're really still going through with that? I didn't expect I'd have to find another distro so soon.

Based on my reading of [1] and [2] it sounds a bit more nuanced than "just incorporate s6 into alpine".

[1]: https://ariadne.space/2021/03/25/lets-build-a-new-service-ma...

[2]: https://skarnet.com/projects/service-manager.html

Can you elaborate on why this is relationship-ending for you? https://skarnet.org/software/s6/why.html makes it seem like a reasonable direction.

I'm not the OP, but a past employer used it on some legacy systems. It makes some choices, like avoiding spinning up new processes, that feel like it's been optimized for embedded systems. It uses a new-to-me language, that we never invested time in. So doing things like "send polite shutdown signals, wait 30 seconds, send harsher shutdown signals" became a matter of separate scripts or documentation. In short, you'd need more context for working with it than with other systems.

Your information is incorrect.

"Avoiding spinning up new processes" is incorrect characterization of s6. Processes are not a scarce resource; spawning a process is not a costly operation in the context of process supervision, even on embedded systems. s6 focuses on optimizing some metrics that are indeed important to embedded systems, like RAM use and code path length, but "spinning up new processes" isn't one of these metrics.

It is not, and has never been, necessary to learn execline, the scripting language you're speaking of, in order to use s6. execline is used _internally_, and you can also use it in your own scripts if you so choose, but it is not a requirement.

"Sending a polite shutdown signal, waiting for some time, and sending a harsher shutdown signal" is a matter of exactly one command: s6-svc -d. That is precisely one of the benefits of s6 over other daemontools-style supervisors: it handles this sequence natively.

I welcome fact-based criticism of s6. I do not welcome FUD-based criticism.

It will only be an option, you can keep sysvinit + openrc if you prefer it this way.

what's the objection?

How about alpine-systemd?

Why would Alpine need systemd? Why would you need it in a container?

Why would you assume Alpine is only used for containers? I use it for my own local home server, as it's very lightweight and easy to tweak to how I want it.

Not to mention every postmarketOS-running phone and tablet.

I don't think there are many of those...

I'm not a fan of using Alpine in containers.

Use it baremetal for your servers and desktops, then use Debian/CentOS containers on top when something is missing.

Sadly when playing the CVE game, Debian containers are no contest to alpine. For CentOS in a container I can see absolutely no reasons except if the SW is only tested against it.

To make sure that once services are up and running, they keep running and are restarted automatically? To have good, centralized logging? To manage in-container services the same way you do on the container host?

There's plenty of good reasons for one to want to do so.

I think it is counter to best practices to run multiple services in a single container. Although maybe you just need to with some proprietary software.

No, it's just another way how to do things.

None of those things are actually needed in a container.

If you're actually doing those things inside one, you're literally doing it wrong

Yes you might have some special cases where some of this is needed but I'd use anything besides systemd

Some use-cases do require an init-providing process of some sort but you likely want to use tini.

See for more details: https://github.com/krallin/tini/issues/8#issuecomment-146135...

a) Starting all your services and shims and mocks inside a CI/CD tests container is not "doing it wrong"; in fact, it's the only correct way to do it.

b) systemd is the only thing that can start services cleanly and correctly. Every other solution is in various states of brokenness.

All of the cheap Linux container hosting services are doing it wrong, I guess.

Many of them offer k8s out of the box.

I still think that orchestration should live outside containers, whether within one box or several. BTW systemd has some vestiges of container orchestration built in.

OTOH there are other approaches; say, LXD directly assumes an ecosystem of processes within a container, more akin to a VM than to a single chroot-ed / jailed service process.

> OTOH there are other approaches; say, LXD directly assumes an ecosystem of processes within a container, more akin to a VM than to a single chroot-ed / jailed service process.

Those are what I had in mind. Basically cheaper VPS like service but built on Linux container tech instead of full virtualization. Maybe they are less of a rage these days, when fully virtualized KVM/Vmware VPS are so cheap. But about 5 years ago I did run my email server, webserver and database on such a container for $1-1.5$/mo. When I was able to switch to full virtualization at similar price point, I did. But there's nothing weird about runing multiple different processes in a "container" :)