The road forward for systemd

Posted May 27, 2010 11:04 UTC (Thu) by liljencrantz (guest, #28458)
In reply to: The road forward for systemd by mezcalero
Parent article: The road forward for systemd

Lennart, I've read your blog post, this article and the comments on both. I think I've wrapped my head around most of it, could you just confirm that my understanding is correct on these points?

* [x]inetd only allows you to load services either lazily (start service when first needed) or on demand (start service once per request). Systemd has a third option, to load a service at systemd startup, right after all sockets have been created. This third option is probably the one that will be used the most.
* [x]inetd handles network sockets, systemd also handles unix sockets and file systems in exactly the same way.
* Unlike upstart, systemd does not solve the problem of automatically restarting services if they go down.
* There is no dependency checking when stopping services, so I can't make it so that when I restart postgres, my web service will be automatically restarted too. Your solution is to fix all services that can't gracefully handle downtime in their dependent services. Your rationale is that they will run into that problem when the services are on different machines in the future anyway.
* Enabling systemd support in a daemon can be a fair bit of work since it requires the ability for the daemon to take over an already open socket instead of creating a new one, but many popular daemons already support this because it's what launchd does too. A service that supports launchd can be trivially ported to systemd.
* If one does not convert a server to systemd init and opts to use the sysvinit compatibility layer, boot performance will be unchanged, but one will still get the increased service control of cgroups.
* If service A takes a long time to start, and service B needs A and has a short time out, problems will ensue. This is likely to happen when A is a name server. There is currently no fix for this in systemd, service B needs to be patched to become more patient.
* Socket location configuration is usually moved from service config into the systemd init file for the service, thus in the common case there is no duplication of information. An exception to this is with services that have both a client and server part running on the same system, and the server part is started by systemd. In these cases, the client side of the service will need to duplicate the socket information somewhere.
* Theoretically, there is nothing preventing upstart from using the same socket trick that systemd and launchd uses, but the existence of pre/post startup scripts would mean that some amount of serialisation would still happen.

The road forward for systemd

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

1. Well, I wouldn't use the terms "lazily" and "on demand" like this (they are completely synonymous in my understanding). But yes, inetd supports one-instance-per-connection and one-instance-for-all-connections modes. And so does systemd.

2. Yes, we currently handle socket-triggered, bus-triggered, file-triggered, mount-triggered, automount-triggered, device-triggered, swap-triggered, timer-triggered and service-triggered activation. And the socket-based activation not only covers AF_INET and AF_INET6, but also AF_UNIX and classic named file system fifos. And the sockets can do all of SOCK_STREAM, SOCK_DGRAM and SOCK_SEQPACKET.

3. Of course, systemd can restart daemons for you just fine. And it does so out-of-the-box for many of them (such as the gettys). Restarting a service is a core part of process babysitting. And systemd is really good at that.

4. There is dependency checking for the order. However we always say that the shutdown ordering is identical to the reversed startup ordering. Hence you may not independently configure startup and shutdown ordering. Of course manual ordering of this is not necessary when socket/bus-based activation is used.

5. No, in either way the patch is trivial, if launchd is already supported it is a bit shorter even. For the 10 daemons (or so) in the F13 default install no took more than 10 or 20 lines of changing.

6. Even if you define no native services, and rely exclusively on SysV services boot-up will be a bit faster than in classic F13 (as an example), since we make use of the parallelization information from the LSB headers (if they are available). Some other distributions (Suse) use that informaton even on classic sysv. Ubuntu does not.

7. And no, I see no problem here. The DNS timeout is 30s or so on most systems. If a DNS server really needs that much time to start up then it is definitely broken. (A simple work-around is to edit the .service file of the client service and add a After= line for your super-slow service.) But anyway, this problem is hypothetical.

8. Well, if you want to connect to a socket service you need to know its address. This has always been like that, and is not changed in any way if systemd comes into play.

9. Sure, Upstart could do that. Not sure though how that fits into their current scheme. I mean, you can hack an emacs clone into the Linux kernel if you want to. There's nothing preventing you from doing that, either.

The road forward for systemd

Posted Jun 1, 2010 23:01 UTC (Tue) by liljencrantz (guest, #28458) [Link]

Thanks for clarifying.