The road forward for systemd

Posted May 26, 2010 19:01 UTC (Wed) by ghigo (guest, #5297)
In reply to: The road forward for systemd by jch
Parent article: The road forward for systemd

I like the idea behind systemd: to start the service only (and if) they are needed. It is not only a speed gains, but also a resource gain: if a service is not required, it will not be started.

The part that I didn't like is that this function is coupled to the init daemon: I would prefer an init daemon very simple, which start a classic sysv init script. The work to "wait for a connection then start the daemon" may be leaved to the script itself.
As someone has pointed out, this is already implemented in (x)inetd. Yes systemd is more powerful but the concept is the same of inetd.

To me it seems that these function is coupled to the init daemon only because the init daemon has certain capability because its pid is 1 [*]. If this is true (may be I am missing something), I prefer to extend the capability of the pid=1 process to other process (via a kernel changing), and separate the function of the init process (start the base system) to the one of a "systemd" process (start the expensive daemon).
This will simplify also the adoption of systemd.

Finally a simple comment: I understand the importance of a quick boot, but today (I have a debian testing, with a no so old AMD system) the major part of the boot time is consumed by the bios booting. So who care a minimal increase of speed of boot, with the risk of a problem in a real critical part of a linux system. In case of init failure the system is blocked!

[*] IIRC The pid=1 process, has the capability to adopt any process which lost their parent.

The road forward for systemd

Posted May 26, 2010 19:19 UTC (Wed) by mezcalero (subscriber, #45103) [Link] (3 responses)

hey, you haven't read the original blog story. please do. it should tell you why xinetd is a very different beat from systemd.

i really wish people would read the blog story before commenting here. many of the issues raised again and agin are already explained there in detail.

The road forward for systemd

Posted May 27, 2010 7:50 UTC (Thu) by ghigo (guest, #5297) [Link] (2 responses)

I read the blog. In fact the author says:
<cite>
The idea is actually even older than launchd. Prior to launchd the venerable inetd worked much like this: sockets were centrally created in a daemon that would start the actual service daemons passing the socket file descriptors during exec(). However the focus of inetd certainly wasn't local services, but Internet services (although later reimplementations supported AF_UNIX sockets, too). It also wasn't a tool to parallelize boot-up or even useful for getting implicit dependencies right.
</cite>

I wrote that systemd is more powerful than (x)inetd, but the concept is the same.

The road forward for systemd

Posted May 27, 2010 8:04 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

You are replying to the same author of the blog post and developer of systemd, FYI.

The road forward for systemd

Posted May 31, 2010 15:34 UTC (Mon) by mezcalero (subscriber, #45103) [Link]

I am the author of the blog story. And there I try to make clear that systemd is substantially more then inetd. inetd is for lazy-loading services. systemd uses the same technique but does so to parallelize boot-up and make dependency information redundant.

So, please, don't compare systemd with inetd too much, because that misses the core point.

If you don't see what the difference between systemd and inetd is, then please read the story again, particularly the part about "Parallelizing Socket Services".

The road forward for systemd

Posted May 27, 2010 8:37 UTC (Thu) by marcH (subscriber, #57642) [Link] (3 responses)

> Finally a simple comment: I understand the importance of a quick boot, but today (I have a debian testing, with a no so old AMD system) the major part of the boot time is consumed by the bios booting.

Lucky you.

The road forward for systemd

Posted May 27, 2010 9:04 UTC (Thu) by dgm (subscriber, #49227) [Link] (2 responses)

Or extremely unlucky, if you think of it. My Lucid UNR takes about 30 seconds from grub to desktop. If his BIOS takes longer than that there's something definitely wrong with his machine... or he's talking about one of those servers with RAID that take forever to boot.

The road forward for systemd

Posted May 27, 2010 14:41 UTC (Thu) by kronos (subscriber, #55879) [Link]

My Asus (M4A79) board has a marvel controller with it's own option BIOS, and I've added an extra PATA controller.
With Asus ExpressGate enabled (default) it takes 38 second from power on to grub...
Without EG it takes "only" 26...

The road forward for systemd

Posted Jun 3, 2010 7:33 UTC (Thu) by eduperez (guest, #11232) [Link]

Some RAID controllers are painfully slow, and I mean they take several minutes to initialize and start loading the boot manager.