S6 can format your hard drive and you still will think that it's "high quality".

It's quite clear that you are resistant to facts and basically venerate crap code only because it's not systemd.

Nope, show me a full SysV compatible script that runs Apache with S6 utilities.

Doesn't matter. This code is crap.

Been there, done that. I ran systemd with my implementation of journald that submitted data to our logger through high-speed hypervisor interface. Worked like a treat. We also have custom implementations of many systemd units.

Nope. systemd is immune to these kinds of issues, cgroups are controlled in the core and it can't crash due to OOM or resource starvation (since PID1 is special).

So is systemd. Critical parts of it are barely 10k SLOC and have been audited well.

Which they were not. Any sane reviewer would have vetoed code that has gotos back into inner blocks.

You have unavoidable race conditions with wrapper scripts dying before they can update the state in some third-party registration system. And this third-party system becomes a critical component that has to be treated as PID1. At which point any sane person would ask "why not put it in PID1 then?".

Because it can. Other types of resource exhaustion are also possible, like nr_files. systemd is utterly reliably in this case and any competing manager will have to be just as good. You're not writing software that works only in the "happy case" when nothing goes wrong?

Nope. systemd is quite evidently easier to extend and customize. It's trivially easy to replace pretty much all of its components. You can't do that with S6, it expects only a very particular set of wrapper scripts that behave in very particular way.

Sure. And by the time you do it CORRECTLY, closing all the loopholes and race conditions, you will get systemd.

Try that with Apache.

Nope. All of the code in nosh is crap. Like convert-fstab-services.cpp. And it's crap according to common definitions - cyclomatic complexity and other commonly recognized bad code practices. For example, "create_geli_bundle" function takes 13 arguments (and it's NOT an outlier).

You are not getting it. Double forking is not "required". It's what real-life programs do, including closed-source systems that can't be modified. Moreover, even well-behaved daemons can accidentally (or as a result of an attack) do what amounts to double-forking. You can't wave it away.

This can be solved using cgroups-polling daemons in addition to cgroups-handling chainloaders. Not trivial, but still cleaner than systemd. The reason it is not yet done is because handling double-forking escapes has not become a hard requirement for enough people.

No, you can't be. Any chainloader can contain a bug that does "rm -Rf". Or it can simply hang indefinitely, leaving PID1 without any information about its state.

And since PID1 in S6 does not manage cgroups, it can't reconstruct the state of the system. This introduces a whole new class of bugs that simply can not exist in systemd.

And they are not even hard to trigger in S6. For example, it won't be able to detect the OOM killer reliably. It's entirely possible for it to lose track of services if the OOM killer happens to kill a newly launched supervisor at an inopportunate moment.

So? They are just binaries that have the source code that lives in the same repo as systemd. That's exactly what "modularity" is.

As I demonstrated, double-forking escapes can happen accidentally. And s6-fghack does NOTHING to deal with it. At all.

No, they are not init-agnostic. They can't be used with SysV init, for example. You'll need a wrapper script that would adapt them to SysV conventions.

I actually did. Quite a few of them are linked into nosh itself ("modularty-shmodularity"), like "move-to-control-group". It's also a TOTAL CRAP code. Yes, with caps. Example right here: https://gist.github.com/Cybera... - a goto jump back into the body of an "if" statement. Mixed with incoherent error handling - the body of an error is printed to stderr with an additional C++ exception.

The first versions of systemd actually had the core just right - RELIABLE service monitoring with full SysV compatibility. S6 has neither.

Except it doesn't work. And never mind that many daemons actually do close all descriptors before double-forking. Learn some Unix, noob: https://codingfreak.blogspot.c...

No, it does not make it easier to "reason" about. In systemd you have a function that scans the cgroup and gives you a "true" result if it's empty. Replacing it with an external utility does nothing at all to make it easier to reason about.

Sure. Let's do it! sloccount on nosh results in 79,712 total lines of code. Not all of it is crucial, but I'm lazy. And anyway, it's not all! We also need at least dash, because nosh needs shell to function, that's at least 13,365 LOC. And then you'll also need some shell utilities. I'm too lazy to look into them right now. Let's put it at 100kLOC.

Now let's look at systemd. It's self-contained and only needs glibc to function, it's possible to boot a working system without a shell. You need the following projects: libsystemd (35,733), journal (19,184), core (52,190). The total is 107107 LOC, and that's including unit tests (too lazy...). And that's it. It's self-contained and reliable, with the core size about the same as in "lightweight" systems. Everything else in systemd is contained in modular helper processes, that can be ignored or replaced at will with something else.

A daemon can double-fork and escape from the supervision of the init system. S6 would require all daemons to be rewritten to work with it. Meanwhile, systemd can reliably work with unmodified double-forking services.

No, they can not. They will encode the assumptions of the underlying init system.

Many of the run scripts are interchangeable across toolsets. Don't be fooled by the use of execlineb, s6-xyz tools, and nosh package tools, for each package. One can quite happily use execlineb or s6-xyz tools in a run script with the nosh package, or vice versa for that matter. One could use chpst under perp, or runtool under daemontools-encore. The fact that daemontools, daemontools-encore, freedt, and runit are mostly all in one column should be taken as the stronger indicator here; there's no strict lock-in of run scripts to any toolset.

Now you're completely incoherent. If your magic wrapper script has a root bug (and let's be honest, shell scripts will be choke-full of them) then this script will have to be fixed, just as systemd had to be fixed.

Since they are not used in real world, of course they do not work better.

In particular, S6 can't work with unmodified daemons that do double-forking. It can be retrofitted with cgroups, but then you'll have an unholy mess of processes - each daemon will have its own overseer process which simply polls a cgroup. If an overseer process is killed by mistake, the daemon process it controls will be an untethered zombie.

cgroups are crucial to the functionality of systemd. In particular, they are also used to detect the daemon death (when no processes are left alive). Sure, you can use external utilities to do that, but they are going to be critical parts of the system.

Moreover, cgroups manipulation takes comparatively few lines of code in systemd. Interaction with external wrapper scripts will necessarily take more.

What's even worse, it's going to be unreliable. If a wrapper script misbehaves or dies (because of an errant SIGKILL, for example) then the system will be left in an indeterminate state. PID1 won't know which cgroups need to be cleaned up. Just as a reminder, PID1 is uniquely protected against SIGKILLs in Unix.

It's pretty clear that none of "veteran" developers actually thought about reliability. But this is no wonder, they know nothing about modern system design.

I don't see how it makes integration trivial. The way to do it is for the init system to set up cgroups and then launch the daemon there. You can even do that with SysV init. If you have to use wrapper scripts ("chainloading") then perhaps you should change your system.

And nope, it has nothing to do with service definition as you still need to at least encode dependencies.

1. To keep track of the process tree - classic Unix does not have any means to keep track of children launched by the daemon process. 2. To keep track of resources and impose resource limits, such as CPU fairness, memory use or disk IO bandwidth.

Classic Unix does not have a reliable way to track process' children to be able to reliably kill an unresponsive or (intentionally) misbehaving daemon. DJB's daemontools tried to use process groups for that, but quite a few services launch child processes in the their own groups.

You are an idiot. Yes, you ARE an idiot.

You certainly can. Feel free to write a script generator that translates unit files into init scripts. The fact is, before systemd nobody was actually doing that. And somehow Devuan developers and other crazies haven't managed to do that in the last 10 years.

"Bernstein chainloading" - nope. It's not a replacement for cgroups and you're an idiot if you suggest this. Neither does it have any relation to service definition.

TLDR; version is - nobody has yet produced an init system that is even remotely competitive with systemd. Do this and then we can discuss if it's better.