Busybox removes support for systemd

> ...are you claiming that openrc is BETTER than systemd...

If I were making that claim, I would have made it.

OpenRC's sysvrc replacement is at least as good as systemd's sysvrc replacement. Moreover, I have much more faith in abilities and reasonableness of the OpenRC Cabal than I do those of the Systemd Cabal.

> True - but that is a good question by itself right ? Why...

I'll ask again. Can you get into specifics about why "[d]eploying web-services on systemd is so much better..."? All I'm getting from you is soundbites and equivocation.

> ...[systemd] is making my linux machine extremely stable...

In the ~20 years that I've been using Linux, I've never had instability introduced by an init or RC system. What init or RC-induced instability have you observed in your Linux systems?

> Supervisord ... [has the] same concept of unit files, declarative language,etc ...

Does this mean that that the meaning of the keywords and parameters in supervisord's config files is very close or identical to those in systemd? Or does it just mean that supervisord's configuration files are in .INI format, just like systemd's?

If the latter, then who cares?

1) Superficial syntax similarities do not necessarily enhance understanding. In cases where similar keywords mean differing things in two different systems, they can (and often do) cause confusion and misunderstanding.

2) Startup files for services whose startup sequence is the most complex you can handle in a systemd unit file are equally terse and readable in both systemd and OpenRC. [0] If the startup requirements are more complex than this, systemd has to call out to a shell script(!) or other external program. OpenRC (and other sysvrc replacements) that use interpreted startup scripts can bake such functionality right in to the startup script. This means that -in these systems- you only need to ship and maintain one file, rather than two. ;)

> Where is [systemd] making everyone's life hard...

Systemd is worrisome for several reasons:

1) systemd's scope continues to creep.

2) The Systemd Cabal continues to assert that pretty much every part of systemd is optional. An honest look at the state of systemd and projects like Gnome puts the lie to that statement.

3) Systemd continues to assert that systemd is faster than anything out there. Real-world observation indicates that this means that they've never heard of -say- OpenRC.

4) The Systemd Cabal continues to assert that systemd is modular. They assert that anyone can read their documentation and reimplement any part of systemd. Many people have attempted to do this and found the documentation sorely lacking.

5) The Systemd Cabal aggressively refuses patches that fix breakage that they introduced by changing decades-old behavior for no better reason than "The behavior was legacy and thus broken.". [4]

In short, the attitudes of the people in charge of the project are dreadfully worrisome. Having udrepper in charge of glibc was bad enough. Systemd's devs are substantially more bullheaded, and the project itself is angling to swallow almost all of Linux userspace.

[0] See Nailer's representative systemd unit file at [1] and my conversion of it to an OpenRC startup script. [2] Also, notice the confusion that one has when one is not already familiar with the keywords contained in a systemd unit file. [3]

[1] https://news.ycombinator.com/item?id=10355588

[2] https://news.ycombinator.com/item?id=10357010

[3] https://news.ycombinator.com/item?id=10356330

[4] Their attitude on such things has been summarized as "Fuck your usecase.".

That's very interesting, I didn't know SMF could do that.

Let's see... init(1) is apparently restarted by the Solaris kernel automatically, which is different from Linux, no automatic kernel panic.

https://github.com/illumos/illumos-gate/blob/master/usr/src/...

  * State File and Restartability
  *   Premature exit by init(1M) is handled as a special case by the kernel:
  *   init(1M) will be immediately re-executed, retaining its original PID.  (PID
  *   1 in the global zone.)  To track the processes it has previously spawned,
  *   as well as other mutable state, init(1M) regularly updates a state file
  *   such that its subsequent invocations have knowledge of its various
  *   dependent processes and duties.

Then init(1) and SMF's svc.startd(1) seem to have a bit of a relationship:

  * Process Contracts
  *   We start svc.startd(1M) in a contract and transfer inherited contracts when
  *   restarting it.  Everything else is started using the legacy contract
  *   template, and the created contracts are abandoned when they become empty.

So init(1) creates the initial contract for svc.startd(1), then the latter creates nested contracts below that. (Aside: doing the equivalent cgroup manipulation on Linux would run afoul of the notorious one-writer rule.)

If svc.startd(1) crashes, init(1) will restart it inside the existing contract of the crashed instance, so it can find its spawned services (in nested contracts), as well as its companion svc.configd(1).

Now during startup, svc.startd(1) calls ct_event_reset(3), and this is really the interesting bit here:

https://github.com/illumos/illumos-gate/blob/master/usr/src/...

     The ct_event_reset() function resets  the  location  of  the
     listener to the beginning of the queue. This function can be
     used to re-read events, or read events that were sent before
     the  event endpoint was opened. Informative and acknowledged
     critical events, however, might have been removed  from  the
     queue.

I'm willing to entertain the idea that with this feature, SMF can properly track the state of the services that its previous incarnation launched, even if it crashed in the middle of handling an event.

With any luck it will also handle the situation if a supervised process exits after the service manager crashes, and before it is restarted, as the contact should buffer the event in the kernel until it is read.

Notably this is a Solaris specific kernel feature of the contract(4) filesystem; does Linux have anything equivalent in cgroups or somewhere?

The other SMF process, svc.configd, uses an SQLite database (actually 2, a persistent one and a tmpfs one for runtime state), so it's plausible that it's properly transactional.

> If we take your logic to its conclusion, we should just run everything in ring 0 with a single unisolated address space, because hey, anything can fail.

That is an entirely erroneous extrapolation, as I never claimed any other single point of failure [in user-space] than the service manager.

Remember that vezzy-fnord was responding to a comment that made the following erroneous statement:

> systemd is NOT making the change to manage cgroups from PID1. Kernel is...

I've heard systemd proponents assert that both udev and the cgroup manager must live in either kernel space or in PID 1, because to do otherwise would expose systemd to races or something while PID 1 started udev and/or the cgroup manager.

These are also erroneous statements. It's rather important to correct such statements, as we're dealing with a (sadly) highly politicized technical topic.

point taken.

actually, I was referring to https://www.debian.org/vote/2014/vote_003 . But I see how my language could be interpreted that way.

I think there has pretty much always been trolls on the internet. Back in the 90s it felt like no one took the happenings on the internet all that seriously, it was a bit of a lark. Now that it's much more mainstream, it's embedded in our everyday lives and companies make a lot of money from it. So it would make sense that everyone takes it a lot more seriously and it's easier to troll people if they take you seriously.

Although not all haters are trolls of course, but it's really hard(impossible?) to tell over the internet (Poe's law), especially when you have haters, fanatics and trolls all playing each other and the only person who wins is the troll in that scenario.