Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
The road forward for systemd
Posted May 26, 2010 21:11 UTC (Wed) by spaetz (subscriber, #32870)
> That meant that for each connection a new process was spawned and initialized,
> which is not a recipe for high-performance servers.
> However, right from the beginning inetd also supported another mode,
> where a single daemon was spawned on the first connection, and that
> single instance would then go on and also accept the follow-up connections...
Inetd is not just for restarting lazily on every new connection it can be used to lazily start on first use and continue running. Which seems to be exactly what systemd also proposes. I know people are going to tell me to read Lennarts blog, I still fail to see how an upstart/inetd combo can't basically achieve most of what systemd achieves. But I might just be dense there. I'll wait for the dust to settle and happily use whatever makes my box boot up...
Posted May 26, 2010 22:54 UTC (Wed) by mezcalero (subscriber, #45103)
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.
Posted May 27, 2010 0:10 UTC (Thu) by dbenamy (subscriber, #39458)
Posted May 27, 2010 6:39 UTC (Thu) by mezcalero (subscriber, #45103)
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.
Posted May 27, 2010 14:07 UTC (Thu) by BenHutchings (subscriber, #37955)
Posted May 28, 2010 9:31 UTC (Fri) by liljencrantz (subscriber, #28458)
Posted May 28, 2010 10:23 UTC (Fri) by michich (subscriber, #17902)
No, the backlog length must be set by userspace when making the socket listen, see listen(3p):
int listen(int socket, int backlog);
Posted May 28, 2010 10:33 UTC (Fri) by michich (subscriber, #17902)
Posted May 31, 2010 16:11 UTC (Mon) by mezcalero (subscriber, #45103)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds