The road forward for systemd [LWN.net]

The road forward for systemd

Posted May 26, 2010 22:54 UTC (Wed) by mezcalero (subscriber, #45103)
In reply to: The road forward for systemd by spaetz
Parent article: The road forward for systemd

inetd was designed to lazy-load daemons. while you can also lazy-load daemons like this in systemd the main points why we want the socket based activation is that we can parallelize bootup and not have to manually configure dependenciea:

we can start syslog and dbus and avahi at the exact same time, even though avahi needs both syslog and dbus, and dbus needs syslog too. because the kernel will queue the requests, and at no time the sockets will be inaccessible, and the kernel will do all the ordering for aus for free. if dbus sends something to syslog, then that data will be buffered in the kernel socket buffer and delivered only when syslog is ready to process it. and until that time dbus can already go on and do other thinga, without having to wait for syslog to startup.

syslog, dbus, avahi work with af_unix sockets, which were out-of-scope for classic inetd.

so, let me stress again: everybody who claims that systemd was about lazy-loading daemons didnt understand the idea. systemd is about utilizing the socket logic to maximize what we can parallelize, and minimize the amount of dependencies that need to be configured.

and all of this you find explained in the blog story. its just noise i have to repeat that here.

(Log in to post comments)

The road forward for systemd

Posted May 27, 2010 0:10 UTC (Thu) by dbenamy (subscriber, #39458) [Link]

I've read the whole blog post and your comments and I'm not sure I understand how you're answering the question. Sure inetd and systemd have different intended purposes, but that doesn't mean the mechanism isn't the same. I guess I'm wondering, is there any difference between the socket portion of systemd and running inetd early at boot to manage all the services mentioned with it's "keep the daemon running" mode?

The road forward for systemd

Posted May 27, 2010 6:39 UTC (Thu) by mezcalero (subscriber, #45103) [Link]

ok, here's another try to explain this. in systemd there are three phases:

1. we set up all sockets, af_inet and af_unix.
2. after that is done, we start all daemons at the same time
3. and then, the kernel figures everything else out for us, for free

in inetd you only have the first step, and it is mostly about af_inet, not af_unix.

(this is a a simplification btw, its a bit more complex in reality.)

this is explained in the "parallelizing socket services" part of the original blog post.

The road forward for systemd

Posted May 28, 2010 9:31 UTC (Fri) by liljencrantz (subscriber, #28458) [Link]

I don't think you can set that manually, the kernel does that for you.

The road forward for systemd

Posted May 28, 2010 10:23 UTC (Fri) by michich (subscriber, #17902) [Link]

No, the backlog length must be set by userspace when making the socket listen, see listen(3p):

int listen(int socket, int backlog);

The road forward for systemd

Posted May 28, 2010 10:33 UTC (Fri) by michich (subscriber, #17902) [Link]

Looking at the code... It uses SOMAXCONN by default (src/socket.c:socket_init()) and it allows overriding it in the config file with a Backlog=... line (src/load-fragment.c).

The road forward for systemd

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

As already pointed out we set it to SOMAXCONN by default, which should be a very good value for (almost?) all cases. And to cover other cases, we allow you to override that in the .socket file.