Devuan Jessie beta released

Posted May 2, 2016 23:57 UTC (Mon) by anselm (subscriber, #2796)
In reply to: Devuan Jessie beta released by dlang
Parent article: Devuan Jessie beta released

AFAIR, increased boot speed is not a primary goal of systemd. The fact that systemd-based machines tend to boot quite quickly is a side benefit of how systemd deals with unit dependencies during bootup, particularly by aggressively starting lots of things in parallel and doing socket activation for services where possible.

For example, in the traditional setup the rc processor would try to start the syslog daemon while every service that wants to use logging is held up waiting for the syslogd init script to finish. Systemd, on the other hand, simply opens the relevant socket(s) itself so other programs that “depend” on the log service can start sending messages to it even though it isn't actually running yet. Systemd launches the actual syslog daemon once messages come in, and then hands the socket and messages over to it so they can be processed. (This is just for illustration; we know that logging in systemd actually works somewhat differently due to the journal, but the main idea is the same.)

For the user, the net result is that boot times for systemd are typically very short, which is nice no matter why it happens. Having said that, systemd does provide tools that admins can use to investigate where time is being spent during the boot process if they want to identify bottlenecks or make optimisations.

to post comments

Devuan Jessie beta released

Posted May 3, 2016 4:55 UTC (Tue) by dlang (guest, #313) [Link] (5 responses)

no, systemd doesn't just open the socket for the logging daemon to use later, it fires up the logging daemon which then opens the socket receives, buffers, and writes the log message.

systemd isn't magic, you can't just create a socket and have logging happen.

Devuan Jessie beta released

Posted May 3, 2016 5:15 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

I was under impression that data is simply buffered in the default socket buffer? Attempting to read might be counter-productive because of all the possible complications with file descriptors and SCM_RIGHTS.

Devuan Jessie beta released

Posted May 3, 2016 5:20 UTC (Tue) by dlang (guest, #313) [Link] (3 responses)

nope, systemd starts journald which processes the message as it is written, does the SCM_CREDENTIALS looup, buffers the data, writes it to disk, and then listens for requests on another socket for things to read the logs.

As the final step it can also write the logs out to a syslog daemon, including forging the SCM_CREDENTIALS in the kernel so that the syslog daemon gets the correct info when it does the queries.

Nothing so mundane as simply buffering the data somewhere until later in the boot process when syslog gets around to reading it.

the kernel kbuf has been doing that buffering of logs to be read later for many years for kernel messages, systemd didn't need to do anything to make those reliable.

Devuan Jessie beta released

Posted May 3, 2016 5:22 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

Does it do this for all sockets? It makes sense for syslog, but I don't think you can do it with file descriptors.

Devuan Jessie beta released

Posted May 3, 2016 5:30 UTC (Tue) by dlang (guest, #313) [Link]

for other socket activation, systemd doesn't do anything with the data, it just hopes that the kernel buffers are large enough that the sender doesn't block too long while it starts up the daemon that will actually process the data.

This works fairly well when the thing being activated either isn't too complex, or is doing a complex enough task that the added delay on the first use doesn't add too much to the time (printing for example)

Devuan Jessie beta released

Posted May 3, 2016 7:22 UTC (Tue) by anselm (subscriber, #2796) [Link]

Here's Lennart Poettering on socket activation in systemd.

Devuan Jessie beta released

Posted May 3, 2016 10:55 UTC (Tue) by paulj (subscriber, #341) [Link] (1 responses)

journald is quite nice.

As for systemd making boot faster by aggressively parallelising things, as per another sub-thread, this has the downside of exposing utilities to parallelism that they were never designed to handle, which can actually *severely* _slow_ boot. Again, my experience with systemd is that my boot has gotten *many times* slower.

Even when everything behaves, I've noticed in the past the massively parallel approach can thrash the disk somewhat. I'm not entirely convinced throughput of boot is always as improved by this as it could be. It might be better to limit the number of parallel launches somewhat (if systemd doesn't already know to do this).

Devuan Jessie beta released

Posted May 3, 2016 12:03 UTC (Tue) by pizza (subscriber, #46) [Link]

> Again, my experience with systemd is that my boot has gotten *many times* slower.

I don't doubt that you're seeing these results, but it appears to be a rare exception given the overwhelming body of evidence showing large improvements in boot times -- Including *every* experience I've had, from relatively tiny embedded systems to big servers and everything in between.

I suspect that the problem isn't actually due to systemd itself, or even its aggressive parallelism, instead being a misbehaving component whose failure/delay was effectively ignored in the past. But without additional legwork on your part to identify what's going on, the situation isn't likely to change.

(As an aside, the 12-core workstation under my desk at the office boots up Fedora 23 faster from spinning rust than CentOS6 does on an SSD, despite the former actually starting up more stuff and attaching some network mounts..)