Introducing /run

Posted Mar 30, 2011 15:50 UTC (Wed) by ovitters (guest, #27950)
In reply to: Introducing /run by handock
Parent article: Introducing /run

Could you please troll somewhere else? Thanks.

to post comments

Introducing /run

Posted Mar 30, 2011 17:21 UTC (Wed) by rwmj (guest, #5474) [Link] (8 responses)

The original post isn't a troll.

It's true that systemd replaces shell init scripts with C, and it's at least arguable that the C code will be more buggy than the shell scripts.

The question though is whether it matters that the shell scripts are replaced with C.

After all, you weren't really supposed to edit those init scripts, and they were written in a highly formulaic variety of shell with lots of canned functions. It was very easy to make mistakes in those shell scripts, and keeping them all up to date with the latest LSB/init standards was a constant battle.

Instead of editing those shell scripts, you should use /etc/sysconfig to make changes to how daemons start up.

Furthermore, systemd AIUI can use init scripts if you want to.

Introducing /run

Posted Mar 30, 2011 17:26 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

"The original post isn't a troll."

Certainly silly to get all railed up and call Lennart a troll for being a messenger in a widely agreed upon and sensible change. The other criticism happens to be invalid as well as you have pointed out.

Introducing /run

Posted Mar 30, 2011 17:53 UTC (Wed) by dcg (subscriber, #9198) [Link] (3 responses)

IMO it's not correct to say that the shell scripts have been replaced with C. The logic of the init system has certainly been rewritten in C. Some daemons have been modified to be able to be run without needing to do any shell parsing (and I don't understand why it would be a bad thing). But what dictates the behaviour of the init process is not C code, but configuration files. So, most of the real meat of the init system has not been rewritten in C code, but "systemd configuration code". Which are easily hackable...

Introducing /run

Posted Mar 31, 2011 2:12 UTC (Thu) by k8to (guest, #15413) [Link] (2 responses)

The problems are:

- it is not a widely agreed upon change
- it makes the system markedly worse according to the inspectability axis

Introducing /run

Posted Mar 31, 2011 16:54 UTC (Thu) by vonbrand (subscriber, #4458) [Link]

Please...

Major distributions have adopted/are considering it (Fedora, Debian, OpenSUSE at least)
"Inspectable" for whom? The maze of shell scripts legated by sysvinit isn't exactly transparent... Sure, systemd does get some using to, but from my (rabid Fedora fan, rawhide follower; and thus user for some time now) perspective it's much better than what came before; plus is promises to really handle dependencies, not just "(try to) start this after that one on boot, and hope for the best" ordering.

Introducing /run

Posted Apr 1, 2011 3:57 UTC (Fri) by motk (subscriber, #51120) [Link]

O_o ~= my face when tangled knots of SYSV shell are described as 'inspectable', ignoring the rampant emergent complexity and entropy therein.

Introducing /run

Posted Mar 30, 2011 18:47 UTC (Wed) by aliguori (guest, #30636) [Link] (1 responses)

It's true that systemd replaces shell init scripts with C, and it's at least arguable that the C code will be more buggy than the shell scripts.

I think that's a simplification of what systemd does and puts too much importance on language which I think is really just an implementation detail here. My understanding of systemd is that it eliminates the explicit dependency expressed in most init systems with an implicit one largely by using file descriptor inheritance.

Since most tools really don't depend on an application to be running, but just depend on being able to open a socket, you can tremendously simplify the problem by making all of the sockets available at once and starting pretty much everything in parallel.

Since startup dependencies are now simplified so greatly, the per task startup is simplified so much that for the most part, it's trivial to do it all with just plain C.

So a better way to think of it is that systemd doesn't replace init scripts with C, it fundamentally eliminates the need to have init scripts by tremendously simplifying the problem of starting up tasks with complex dependency hierarchies.

Introducing /run

Posted Mar 30, 2011 20:31 UTC (Wed) by vonbrand (subscriber, #4458) [Link]

I think that's a simplification of what systemd does and puts too much importance on language which I think is really just an implementation detail here. My understanding of systemd is that it eliminates the explicit dependency expressed in most init systems with an implicit one largely by using file descriptor inheritance.

Make that no dependencies and we'll agree (The standard init stuff just says in which order stuff should (!) be (tried to) run when the system starts in a given runlevel, nothing more. Fragile as hell, but even so vastly better than what came before...).

Introducing /run

Posted Mar 30, 2011 23:42 UTC (Wed) by rgmoore (✭ supporter ✭, #75) [Link]

I'm not sure that's a fair description of what systemd does. The biggest thing it does is to refactor the init system. It takes the boilerplate part of all the init scripts and combines it into a single implementation in C, and turns the small variable part into config files. Eliminating the copy and paste proliferation of independent init files should tend to reduce bugs, not increase them.