Introducing /run

Posted Mar 30, 2011 18:47 UTC (Wed) by aliguori (guest, #30636)
In reply to: Introducing /run by rwmj
Parent article: Introducing /run

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.

to post comments

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...).