The road forward for systemd [LWN.net]

The road forward for systemd

Posted May 27, 2010 4:27 UTC (Thu) by elanthis (guest, #6227) [Link] (2 responses)

Inetd does not do what systemd does. Apparently you got as far as "starts daemons when things connect to the proper port" and stopped reading there, and in turn are just talking out your ass without understanding what you're talking about. Read the freaking article and quit wasting your time and our time.

The road forward for systemd

Posted May 27, 2010 14:35 UTC (Thu) by sharms (guest, #57357) [Link] (1 responses)

You rebutt his comment without explaining why it is wrong. That does not make sense.

The road forward for systemd

Posted Jul 7, 2010 10:15 UTC (Wed) by geocar (guest, #68511) [Link]

The comment is rebutted in the article. systemd and inetd are as meaningfully similar as postfix and stunnel, and maybe less so.

The novelity is in combination of ideas...

Posted May 27, 2010 7:42 UTC (Thu) by khim (subscriber, #9252) [Link] (4 responses)

Let's talk about simple example: avahi, dbus and syslogd. avahi uses dbus and both dbus and avahi use syslogd. Suppose they spend 1second to initialize and only then start talking with each other.

Init and upstart know the dependences and do the following:
1. Start the systlog.
... 1 second passes ...
2. Start the dbus.
... 1 second passes ...
3. Start the avahi.
... 1 second passes ...
4. System is usable.

inetd does the following:
1. Start the avahi.
... 1 second passes...
2. dbus is requested and syslog is requested too - start them...
... 1 second passes...
3. System is usable.

systemd does the following:
1. Start avahi, dbus and syslogd.
... 1 second passes...
2. System is usable

This is idealized example, but it shows the difference. The fact that systemd can start services both from the list and on-demand guarantees the fastest possible boot speed - and other interesting properties too.

The novelity is in combination of ideas...

Posted May 27, 2010 16:01 UTC (Thu) by spaetz (guest, #32870) [Link] (3 responses)

Thanks, that was a very instructive post that made me -for the first time- see the advantage that systemd provides over current systems. Let me pose one question though.

> Init and upstart know the dependences and do the following:
> 1. Start the systlog.
> 2. Start the dbus.
> 3. Start the avahi.
> 4. System is usable.

I agree with init, but doesn't upstart support parallel starting? So upstart might rather:
1)Request avahi start
2)Start dbus and syslog as prerequisites
...1 sec passes
3) dbus and syslog are up, start avahi
...1 sec passes
4)System is usable

Am I wrong here?

> inetd does the following:
Right. 2 secs and no explicit dependency info needed.

> systemd does the following:
> 1. Start avahi, dbus and syslogd.
> ... 1 second passes...
> 2. System is usable

One of the things I though it that systemd does NOT require explicit dependency information. So how does systemd knows that dbus and syslogd should be started at second 0 whwn avahi is supposed to go up? Nothing requests dbus and syslogd sockets until second 1 when avahi is up, right? So do we need to code in the explicit dependency information into the avahi.service config?

The novelity is in combination of ideas...

Posted May 27, 2010 16:40 UTC (Thu) by spaetz (guest, #32870) [Link] (1 responses)

> One of the things I thought is that systemd does NOT require explicit dependency information.[...]
> So do we need to code in the explicit dependency information into the
> avahi.service config?

I was not sure because the initial blog post both seems to hint that explicit dependencies become redundant:

"Also, dependencies between services will no longer necessarily have to be configured to allow proper parallelized start-up" "...dependency management also becomes redundant..." "[In critique of upstart] So, instead of letting the computer figure out what to do based on the dependencies, the user has to manually translate the dependencies into simple event/action rules."

But it also says that it is possible:

"All these units can have dependencies between each other (both positive and negative, i.e. 'Requires' and 'Conflicts')" "11. systemd supports several kinds of dependencies between units. After/Before can be used to fix the ordering how units are activated. It is completely orthogonal to Requires and Wants,"

So would avahi explicitely specify dependencies on dbus and syslogd in its .service file? It seems it would. BTW, dependencies seem to be better explained in this mail explaining the dependency information in .service files: http://lists.freedesktop.org/archives/systemd-devel/2010-May/000015.html

The novelity is in combination of ideas...

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

Yes, you raise a good question.

To light this up a bit: in systemd you can express both ordering and requirement dependencies. You can both configure them manually, and systemd will automatically add quite a few additional ones for you (Example: we will automatically add a "Requires" dependency from every file system listed in /etc/fstab to the device it is mounted from). However, for most cases for normal services you will not need to manually configure any dependencies, as the various ways of activation will deal with that automatically. Manual dependency configuration is really only necessary for units necessary for the very early boot, or the very late shut down.

Or in other words: we use dependencies internally, we also expose them to the user, but he should only very seldom need to make use of them.

This is a bit different from launchd, which really knows no dependencies at all. For that they pay a certain price though: their early boot-up is done completely differently from the actual service startup. Since our Linux start-up procedure is more complicated then theirs we hence decided to provide both: the dependency-less main boot-up plus manual dependencies for a few special services involved with very early boot.

Dbus uses syslog too...

Posted May 28, 2010 7:16 UTC (Fri) by khim (subscriber, #9252) [Link]

I agree with init, but doesn't upstart support parallel starting? So upstart might rather:
1)Request avahi start
2)Start dbus and syslog as prerequisites
...1 sec passes
3) dbus and syslog are up, start avahi
...1 sec passes
4)System is usable
Am I wrong here?

Dbus needs syslog too, so it can not be started in parallel with syslog if you only go by dependences list

So how does systemd knows that dbus and syslogd should be started at second 0 whwn avahi is supposed to go up?

Dbus and syslog will probably be on the list of "always up" processes. If you'll drop them from said list systemd will start them later because they are requested by avahi.

The road forward for systemd

Posted May 27, 2010 10:37 UTC (Thu) by Tobu (subscriber, #24111) [Link] (1 responses)

My take on the inetd/systemd relationship is that systemd merges init concepts and inetd concepts. You could do things separately, with an inetd that supports unix domain sockets like xinetd, a user-level init like runit, and an optional dependency resolver to configure both (runit starts everything by default, the resolver would have to mask services that aren't explicitly needed at a given runlevel). It just wouldn't be very convenient. xinetd wasn't meant for services that can be activated on multiple sockets, or through d-bus activation. And neither xinetd nor runit support cgroups. On the other hand, a user-level systemd can replace xinetd and runit, or be a hybrid of both.

The road forward for systemd

Posted May 27, 2010 13:15 UTC (Thu) by Tobu (subscriber, #24111) [Link]

For completeness of the UNIXy, modular approach: cgroup support could go into chpst.