Devuan Jessie beta released

Posted May 3, 2016 20:13 UTC (Tue) by dlang (guest, #313)
In reply to: Devuan Jessie beta released by farnz
Parent article: Devuan Jessie beta released

because the declarative configuration still needs to be processed by a turing complete language, so your theoretical advantage of 'knowing' that it will complete in a bounded time doesn't really exist.

The post earlier about how there are now >100 tags that you can use, but many of them only work for specific modules is an example of why a declarative config format just doesn't work well in the real world. There is always going to be some case that you didn't think of when you designed your config. init scripts give you the ability to handle your special case in a way that makes sense to you without having to get a new option defined and propagated to the whole world.

to post comments

Devuan Jessie beta released

Posted May 3, 2016 20:50 UTC (Tue) by farnz (subscriber, #17727) [Link]

I don't buy the "it still needs to be processed by a turing complete language" argument; that's basically saying that because systemd (the unit file interpreter) could be buggy, you can't reason about unit files. The same argument applies to any sort of restriction - when you allow the browser to interpret HTML for display, the "theoretical" advantage of doing so instead of running an arbitrary binary in supervisor mode doesn't really exist, because a bug in your processor could result in the browser's HTML parsing code being interpreted as instructions to wipe the disk.

And 100 directives isn't that large, compared to the set of bash built-ins, especially since not all directives can occur in all sections of a unit file - if this file does not have (for example) a [Mount] section, all the directives that only apply in the [Mount] section are errors; you thus only need to know about the directives that apply to each section. Plus, systemd provides the tooling you need to generate units from code at run-time, if you really the flexibility - but the fact that you're asking me to review a generator instead of a unit file tells me that you're writing a special case, and I ought to look in more depth at your code output.

Devuan Jessie beta released

Posted May 3, 2016 21:34 UTC (Tue) by anselm (subscriber, #2796) [Link] (4 responses)

There is always going to be some case that you didn't think of when you designed your config. init scripts give you the ability to handle your special case in a way that makes sense to you without having to get a new option defined and propagated to the whole world.

Which is presumably why systemd lets you use an init script in place of a unit file if you have to. You'll give up all sorts of other helpful systemd features that way, but if you're really keen on doing everything yourself anyway that shouldn't slow you down a lot. As a half-way solution, systemd service units do allow you to specify arbitrary shell commands to execute when a service is to be launched, and those should be able to let you do pretty much anything if you need to.

In actual practice, init scripts are usually 90% or more boilerplate and you pretty much have to compare them side by side to find if there are subtle differences between any two on your system. In spite of the fact that they're all largely identical they're still in separate files, though, so if you want to enable a feature like runtime monitoring of services or private /tmp directories you have to put it into every single init script by hand and carry those modifications yourself across updates of those init scripts. Having these features provided in one central place and accessible via a configuration switch is a lot more convenient and future-proof and the chances that any bugs will be found and stamped out are way higher if the code occurs in only one place instead of a few dozen.

Devuan Jessie beta released

Posted May 3, 2016 21:40 UTC (Tue) by dlang (guest, #313) [Link] (3 responses)

if you end up with a separate config file for each service, it's not really much better than a separate script file for each service. You still have to touch every file if you want to add something for every service.

I really don't like the "systemd provides a default file and your custom one gets merged with it" approach, I would much prefer a "the distro provides a default that you can replace" Figuring how the two will get merged, and what changes will be introduced with a new systemd version is much worse than getting flagged at upgrade time that there is a new version of the config that you have to look over and merge.

Devuan Jessie beta released

Posted May 3, 2016 21:49 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]

>I really don't like the "systemd provides a default file and your custom one gets merged with it" approach, I would much prefer a "the distro provides a default that you can replace"

You must be aware that systemd allows for either?

Devuan Jessie beta released

Posted May 3, 2016 22:03 UTC (Tue) by anselm (subscriber, #2796) [Link]

if you end up with a separate config file for each service, it's not really much better than a separate script file for each service. You still have to touch every file if you want to add something for every service.

It is if your configuration file is only a dozen lines long in a very simple and robust format, as opposed to a few screenfuls of arbitrary shell script. It would be reasonable to use a script to add a directive to, say, every “[Service]” section of a selection of systemd unit files, but you wouldn't really want to do that to a bunch of init scripts.

I really don't like the "systemd provides a default file and your custom one gets merged with it" approach, I would much prefer a "the distro provides a default that you can replace"

You're perfectly free to do that with systemd, too. Which approach you take would depend on the nature and the size of the changes that you want to make.

Devuan Jessie beta released

Posted May 14, 2016 11:21 UTC (Sat) by HelloWorld (guest, #56129) [Link]

> if you end up with a separate config file for each service, it's not really much better than a separate script file for each service. You still have to touch every file if you want to add something for every service.
And how is that different from what you'd have to do with init scripts? Oh, I know: with a declarative file format it's trivial to automate.

Devuan Jessie beta released

Posted May 14, 2016 11:15 UTC (Sat) by HelloWorld (guest, #56129) [Link] (3 responses)

> because the declarative configuration still needs to be processed by a turing complete language, so your theoretical advantage of 'knowing' that it will complete in a bounded time doesn't really exist.
This sort of non-sequitur really says more about you than about systemd.

Devuan Jessie beta released

Posted May 18, 2016 21:54 UTC (Wed) by nix (subscriber, #2304) [Link] (2 responses)

Is anyone really worried about infloops from init scripts trying to exhaustively prove the infinitude of the primes in any case? Not even Red Hat's pre-systemd init scripts went quite that far.

I can understand why being paranoid about infloops in things like systemtap scripts makes some sense, but in init scripts? Seriously, I have at least one intentional one (it avoids kicking off the watchdog before all the things it should be monitoring have started properly -- the sort of thing that systemd could do without effort, of course...)

Devuan Jessie beta released

Posted May 18, 2016 22:10 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

> Is anyone really worried about infloops from init scripts trying to exhaustively prove the infinitude of the primes in any case? Not even Red Hat's pre-systemd init scripts went quite that far.
You think so?

Try this one: http://anonscm.debian.org/cgit/users/lamont/bind9.git/tre... - see line 92. Granted, that's Debian not RedHat.

Devuan Jessie beta released

Posted May 19, 2016 7:20 UTC (Thu) by farnz (subscriber, #17727) [Link]

Yes, because I caught at least two when I translated an employer's sysvinit scripts to systemd units. In both cases, we'd seen the hang in about 1% of boots, but couldn't diagnose.