The road forward for systemd

Also, equating "a daemon has definitely bitten the dust" with "its cgroup is now empty" might actually work for a nonzero subset of them, though not all.

In summary, IMHO some of systemd's ideas actually make sense and might actually fit into upstart's model of the world. Just a SMOP. :-P

The part that I didn't like is that this function is coupled to the init daemon: I would prefer an init daemon very simple, which start a classic sysv init script. The work to "wait for a connection then start the daemon" may be leaved to the script itself.
As someone has pointed out, this is already implemented in (x)inetd. Yes systemd is more powerful but the concept is the same of inetd.

To me it seems that these function is coupled to the init daemon only because the init daemon has certain capability because its pid is 1 [*]. If this is true (may be I am missing something), I prefer to extend the capability of the pid=1 process to other process (via a kernel changing), and separate the function of the init process (start the base system) to the one of a "systemd" process (start the expensive daemon).
This will simplify also the adoption of systemd.

Finally a simple comment: I understand the importance of a quick boot, but today (I have a debian testing, with a no so old AMD system) the major part of the boot time is consumed by the bios booting. So who care a minimal increase of speed of boot, with the risk of a problem in a real critical part of a linux system. In case of init failure the system is blocked!

[*] IIRC The pid=1 process, has the capability to adopt any process which lost their parent.

Pffffff. Lennart should fix PulseAudio properly first by solving its extreme latency issues, amongst other things, before faffing about with something else.

PulseAudio is the reason I run a Mac. Seriously.

The point is that right now a whole lot of time is wasted synchronously starting daemons that could be started asynchronously. In addition, since the permutations of system configuration necessarily mean infinite startup paths, trying to deterministically manage the startup process is a losing game.

This isn't about network/non-network bias. Many sockets have nothing to do with network sockets. This is about how to manage a network of relationships under uncertainty.

init solves the problem by trying to run everything in order, even if that wastes performance. launchd tries to be much more flexible. systemd establishes rules of engagement and lets the daemons fight it out amongst themselves.

Hope that helps.

ntpd is an interesting one. We cannot really make "gettimeofday" block until ntpd has affirmed that the system time is correct.

Most programs probably don't care if the system time is still just based on the cmos clock, or whether it has been synchronised to the Internet or to GPS or whatever yet. Maybe programs that do care need to check with e.g.

ntpdc -np | awk '$0 ~ /^*/ { print $7}'

rather than just assuming that they were started after 'ntpdate' had run...

I suspect there might be other similar hidden assumptions that need to be found out.

its not different with upstart, which is linux-only, too.

If my understanding is correct:

Presumably when a application requests something from BIND; it will get launched to serve that request.

Sooo... it would go something like this:

1 Application requests name resolution

2 Request goes through the nsswitch stuff. The nsswitch configuration indicates:
hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4

3. So the look up checks your hosts files, tries mdns4_minimal (which should trigger Avahi to start up) then finally ties the 'dns' method.

4. The /etc/resolv.conf file is checked. The resolv.conf has, as it's first entry:
nameserver 127.0.0.1

5a. The code then connects to UDP or TCP port 53 on localhost.

5b. The Systemd configuration method would have bind service conifigured and the systemd stuff will be listenning on port 53 in a inetd-like fashion.

6. Systemd responds to request on localhost port 53 and launches Bind.

Soooo.... To answer your question of:
>How do I mark this dependency?

You configure /etc/resolv.conf to have localhost as a nameserver.

So, you just remove native systemd's postgresql service and use your own pair of init scripts for your site-specific deployment which I don't get, since when you get a dedicated DB box, you won't be able to do this anyway and will have to display "db unavailable" from the webapp whenever it's down.

Not really, you only install/enable services you would have used anyway.

> 2. A nightmare for configuration. Is systemd going to read everyone elses config files to know what ports/interfaces a process should bind to? What about socket options? Does this mean we have to configure these things now in multiple places?

Nope, yes. But since you are already configuring this stuff in multiple places (server, clients), that should not be a big problem. (You really change default socket paths? Why?)

> 3. Pulseaudio's simplistic view of the world still gives me trouble and I can see the same thing happening here. e.g. He's plugged in a HDMI cable, he must what audio over that. No other option, period!!! Too bad my TV doesn't do HDMI audio.

Hmm, are you sure that's a pulseaudio problem? Something tells me that this is handled a bit lower, as in ALSA.

2. No, systemd does not parse anybody else's config files. You can configure everything in systemd's .socket file, including sockopts.

3. Dude, you apparently never used PA. For example: if you have more than one audio device, then things are *way* nicer with PA than without it: you can move active streams between devices on-the-fly. That is pure hotness! HDMI on Linux is still messy and incomplete, but PA certainly plays the least role in that.

Please stop the FUDding!

Some versions of inetd will listen for RPC services (like ypbind or ypserv) and start the daemon only on demand.

It might be a bit tricky if portmap (or rpcbind) were started on demand. You would want to be able to feed it a list of programs/binding to be able to report immediately rather than waiting for them to be registered.

But it is certainly possible.

First of all, you create the impression that systemd’s core design was about dependencies. Well, it is not. Dependencies are supported by systemd only for the purpose of early boot. Normal services should not really use that for much. One of the nice things in systemd is that the kernel will get the dependencies and ordering right for you, out of the box.

Also, it is misleading that the hw hotplug logic would only really make sense in an event-based systemd. But well, that’s not true. It fits really nicely in a system that does dependencies: for example, there is a dependency between “bluetooth dongle is plugged in” and “bluetoothd must be running”. Systems that support dependencies can express that dependency explicitly, while event-based systems cannot.

Did you never get the idea that maybe nobody else is using your event-based design, because it is simply broken? (For the reasons I pointed out in my original blog story.)

Also, claiming that launchd’s or systemd’s core design was around on-demand loading of services is misleading. While we support that too, we do socket-based activation mostly to parellelize boot-up and to get rid of explicitly configured dependencies. Only a few services will actually be started on-demand in a systemd system. Most will be started in any case, but fully in parallel due to the socket activation logic.

Yes, systemd does both socket-based activation and dependencies. Manually configured dependencies are however only really needed for early boot-up or late shut-down and a few other cases. launchd does not support dependencies at all, for the price that their early boot-up is completely seperate from the starting of daemons, while in systemd this can be interleaved quite a bit.

OpenSUSE has already given up all Upstart experiments btw. Right now only Ubuntu uses Upstart fully, and Fedora and RHEL use it in sysv compatbility mode only.

And generally I think it would be nice to talk more about stuff Upstart has actually already accomplished, instead of great plans. In my postings about systemd I kept the part about my plans very short. Almost all features I talked about in my various postings can be listed under “DONE”, not under “WILL BE DOING”.

Note that systemd supports quite a few triggers for starting a service. And they can be combined in various ways. For example, we can start CUPS as a dependency of “printer plugged in”, as well as a dependency of “client requests CUPS services”, as well as “there’s a file in the CUPS spool dir”. It’s all implemented, and works fine. CUPS fits perfectly in the systemd model, as all its triggers are available already. If one of the conditions holds, CUPS is started. I don’t see how the current Upstart could do anything like this… So, on this topic: systemd 1, upstart 0.

And finally, I don’t think you have really understood launchd or systemd. The focus is on using socket-activation for parallelizing and getting rid of explicit dependencies. It’s much less on on-demand loading.

And if cgroups are really so ugly, why didn't anybody point that out when it got merged? Seems you are criticising us for a failure of the kernel community in reviewing the cgroup code then. And that is unfair.

Well, and it is really a very kernel-developer-centric view of the world if you say that running kernels without sysfs or cgroups or stuff like that should work with every init system. But, first of all, kernel developers make up only a tiny fraction of our users, and they are the ones who should be able to pass "init=/bin/sh" to the kernel, to make the system boot up in any case. Also, nothing forces you to use systemd. You can always continue to run SysV init if that makes you happy.

And I fail to see that there was any mess with udev. Also, isn't it a bit unfair if you ask us to basically stop development of userspace where it was 10 years ago, just because you are unwilling to follow any new userspace development and find it boring and stupid in general?

thank you