Systemd 214 Comes "Stuffed With Great New Features"

[ceage]

You raise some valid points. I'm a FreeBSD user, and I've been investigating systemd lately. I retain a lot of criticisms of it, though, which I'll elaborate upon at some time.

What I find particularly interesting is the issue of knowing when a service is up. I notice systemd has a function called `sd_notify()` which serves to indicate to systemd that a service is running. This is a good idea. But most services don't use it. What, then, is system's solution in the case of a service that takes a little time to be ready? Simply waiting a few seconds before launching its dependents? Waiting for (in the case of a Forking service) its PIDfile to appear? Or perhaps (ugh) polling whatever interface the service makes available?

systemd.service(5) is probably what you're looking for, specifically the Type= statement. In short, systemd lets you configure its behavior for such cases.

[JX8p]

Oh, especially the latter one is nasty, but I think both scripts illustrate what is wrong with script based init systems, in that the executable config files tries to make up for the fact that init-system is so simple/stupid it can't handle PID's properly, the arbitrary long wait statements because the init system can't really communicate the state of the programs in a proper and timely way, so the daemon init script has to rely on brute force, the fact that there are workarounds for critical init system bugs (killall) etc.

I don't think those people who made the script are bad programmers; they seem knowledgeable about PID problems etc, and they have documented their code. It is just that they are forced to make up for the many deficiencies of their targeted init-systems.

It also shows how systemd can reduce or remove unnecessary code; the entire first scripts is about guessing language locale, by probing various places such information could be hiding.
On a systemd box, that information is always in the same place, it is a one-liner to get locale (and change it too).

I think SysVinit is an example of "everyday madness" escalated beyond belief. It all started out many years ago as a piece of shell glue that solved a simple problem for simple needs, but later it just grew and grew and people getting so used to thought that they were editing executable config files in order to work around the fact that the init systems lacked rudimentary functionality.
ds be
Total madness, but a state of madness so familiar that some people can't recognize it as such. But the fact is, that dealing with script based init-systems are like attending the Mad Hatters Teaparty.

You raise some valid points. I'm a FreeBSD user, and I've been investigating systemd lately. I retain a lot of criticisms of it, though, which I'll elaborate upon at some time.

What I find particularly interesting is the issue of knowing when a service is up. I notice systemd has a function called `sd_notify()` which serves to indicate to systemd that a service is running. This is a good idea. But most services don't use it. What, then, is system's solution in the case of a service that takes a little time to be ready? Simply waiting a few seconds before launching its dependents? Waiting for (in the case of a Forking service) its PIDfile to appear? Or perhaps (ugh) polling whatever interface the service makes available?

[interested]

To accentuate this point, I would like to provide an example of a particularly horrible (but portable! Therefore it's good, right?) init script:https://github.com/josephholsten/pbi...ebian/lwsmd.in... Not too bad, right? except it includes this horror

When I had to debug problems with that suite of tools I think I saw that mess *duplicated* in another file as well, but I don't remember which file it was; my brain has graciously decided to block out the details.

Oh, especially the latter one is nasty, but I think both scripts illustrate what is wrong with script based init systems, in that the executable config files tries to make up for the fact that init-system is so simple/stupid it can't handle PID's properly, the arbitrary long wait statements because the init system can't really communicate the state of the programs in a proper and timely way, so the daemon init script has to rely on brute force, the fact that there are workarounds for critical init system bugs (killall) etc.

I don't think those people who made the script are bad programmers; they seem knowledgeable about PID problems etc, and they have documented their code. It is just that they are forced to make up for the many deficiencies of their targeted init-systems.

It also shows how systemd can reduce or remove unnecessary code; the entire first scripts is about guessing language locale, by probing various places such information could be hiding.
On a systemd box, that information is always in the same place, it is a one-liner to get locale (and change it too).

I think SysVinit is an example of "everyday madness" escalated beyond belief. It all started out many years ago as a piece of shell glue that solved a simple problem for simple needs, but later it just grew and grew and people getting so used to thought that they were editing executable config files in order to work around the fact that the init systems lacked rudimentary functionality.

Total madness, but a state of madness so familiar that some people can't recognize it as such. But the fact is, that dealing with script based init-systems are like attending the Mad Hatters Teaparty.

[Chousuke]

SysVinit proponents claims that using such shell scripts to start daemons are an advantage, but many other think it is a mess that contributes to the fact that such daemon shell scripts (and the actually system init scripts) are hard to maintain and debug.

To accentuate this point, I would like to provide an example of a particularly horrible (but portable! Therefore it's good, right?) init script:https://github.com/josephholsten/pbi...ebian/lwsmd.in... Not too bad, right? except it includes this horror

When I had to debug problems with that suite of tools I think I saw that mess *duplicated* in another file as well, but I don't remember which file it was; my brain has graciously decided to block out the details.

[interested]

In what way does systemd seperate executable code from daemon configuration that isn't comparable to /etc/rc.conf or /etc/conf.d/whatever vs /etc/rc.d/whatever? Now, I'm not a tremendous fan of shell-script based & unsupervised service management myself, but I'd appreciate if you could elaborate?

It is really basic: The point is that all the systemd "Unit" configuration files are non-executable text files. As a bonus they are structured so they are easy to parse for both humans and software. So if you want to change the configuration on how the init system (systemd) deals with the daemon, you just edit a text file.

On script based init systems, you are actually editing an executable file when you want to change the behaviour of how the daemon is executed by the init system. The implementation details vary from init system to init system, but they all mix such configuration statements with executable code to some degree. People normally don't think that such shell based init scripts are doing this, but they do.

SysVinit proponents claims that using such shell scripts to start daemons are an advantage, but many other think it is a mess that contributes to the fact that such daemon shell scripts (and the actually system init scripts) are hard to maintain and debug.

[JX8p]

Haven't you ever looked at a OpenRC script for a daemon?

Fact one: OpenRC scripts are executable and contains executable code.
Fact two: They contain configuration statements about how the daemon should be configured depending on circumstances, and general config keywords telling the script in which order the daemon scripts should be executed.

The logical conclusion is that OpenRC scripts are executable config files.

You may not like that description because it rather aptly shows what is wrong with that kind of script based init-systems. But it is a fact.

Any modern and sane init-system like systemd, separate the executable code from the configuration of the daemons.

In what way does systemd seperate executable code from daemon configuration that isn't comparable to /etc/rc.conf or /etc/conf.d/whatever vs /etc/rc.d/whatever? Now, I'm not a tremendous fan of shell-script based & unsupervised service management myself, but I'd appreciate if you could elaborate?

[interested]

Thanks for showing us that you actually have no clue what you are talking about.

Haven't you ever looked at a OpenRC script for a daemon?

Fact one: OpenRC scripts are executable and contains executable code.
Fact two: They contain configuration statements about how the daemon should be configured depending on circumstances, and general config keywords telling the script in which order the daemon scripts should be executed.

The logical conclusion is that OpenRC scripts are executable config files.

You may not like that description because it rather aptly shows what is wrong with that kind of script based init-systems. But it is a fact.

Any modern and sane init-system like systemd, separate the executable code from the configuration of the daemons.

[interested]

Again, they are not at all cloning systemd, all they do is writing software that provides the DBUS interfaces provided by some systemd components. Claiming that this would be cloning is the same as claiming that Wine is a Windows clone.

As you yourself point out, this is actually a clone of systemd. Sure, they are only cloning a part of systemd right now, but don't be surprised if further parts of systemd starts to get cloned by *BSD in the near future.

There is a lot of smart people developing the various BSD variants, and when they look at the features and advantages of a modern ini-system like systemd, they will of course want all these goodies. They won't copy systemd directly because the problems systemd solves on Linux are different on *BSD, and for political reasons, they wont launch it as a umbrella project (isn't needed either), but present various bits of their systemd clone as separate from each other.

But the end result is the same; a new BSD init-system where services are configured with structured text files, not executables files where code and config statements are mixed together in a jumble, and where a powerful PID1 enables services to utilize advanced kernel features without the need to re-program the services, and where all processes are centrally supervised etc.

[Truth]

It's been elaborated over and over in previous threads. Use forum search if you're really interested. And no, you can fix a broken design. You can only throw away the design and start over from scratch.

I'm curious, when did you decide to sell your soul to Microsoft? You're obviously very intimidated by systemd, so you attempt to troll it with laughable conspiracy theories.

It's not too late for you. You could still quit MSFT and embrace a open ecosystem.

[Vim_User]

No it hasn't. Systemd isn't broken by design, unlike script based init systems like SysVinit and OpenRC. Come on, who thought it would be a good idea to have executable config files for services, where code and config statements are mixed up in an unstructured text file?

Thanks for showing us that you actually have no clue what you are talking about.