The answers are there, you just don't want to admit they are right answers...

Posted Jun 1, 2010 1:21 UTC (Tue) by paulj (subscriber, #341)
In reply to: The answers are there, you just don't want to admit they are right answers... by nix
Parent article: The road forward for systemd

If systemd does indeed have some simple dependencies, then "system time may now be considered stable" == having a dependency on a script that runs ntpdate -s. I'm more concerned that there may be events that do not fall easily into "write to an fd, at the boundary of process lifetimes (either before or after)" model. Such events are not visible to systemd. If there's a significant amount of those, then you need something higher-level.

E.g. the printer example Lennart gives, and says "printer plugged in" can be depended on. But what if I want to depend on the type of printer? That's treading into udev below and DBus services above, depending on exactly what I want to do. Or "network available" - but what if I want to depend on a certain kind of network interface? Or a certain location (e.g. "start the automounter, for corporate NFS if ...")? Lots of the information you might use there is being maintained by NetworkManager (using DBus to publish that info).

Basically, if we add systemd to the mix, we're going to have udev, then systemd, then DBus + {various DBus services: NetworkManager, ModemManager, gdm, polkitd, bluez, etc}. Do we really need that extra layer of management? And many services modified for systemd would have to bind into a DBus(-like)? layer anyway, to handle in-lifetime events.

The answers are there, you just don't want to admit they are right answers...

Posted Jun 1, 2010 11:56 UTC (Tue) by mezcalero (subscriber, #45103) [Link] (2 responses)

If your event "system time may now be considered stable" shall be about NTP then it makes little sense since NTP clients tend to slowly adjust the time instead of making it jump. That means that the time is adjusted fully only after quite a bit of time. Applications should not wait for that. They should just assume that time is correct, right from the beginning. And that is a safe assumption for all machines built in the last 25y. And again, I don't see what systemd has to do with eventing like that anyway. I see no need to multiplex events through an eventing system. Get your events from the respective subsystems directly. Don't add an indirection layer here.

People should handle "in-lifetime" events (as you call them) with the native notification logic available. no need to involve systemd, or dbus or anything.

The answers are there, you just don't want to admit they are right answers...

Posted Jun 1, 2010 13:33 UTC (Tue) by dlang (guest, #313) [Link]

I don't know what datacenter you are working in, but I sure don't trust the system time in my datacenter until NTP has started, and at initial startup I don't have it gradually adjust the time as it may be so far off that NTP will decide that it will never get it right and shut down. Instead it does a one-time large jump to get the system time correct.

on some systems I use the -G option, on others I use ntpdate.

The answers are there, you just don't want to admit they are right answers...

Posted Jun 2, 2010 6:33 UTC (Wed) by paulj (subscriber, #341) [Link]

It's not a safe assumption unfortunately. There are distressingly many machines out there which deliberately are run without batteries (lower field maintenance) and which hence have the time set at boot. Note that "ntpdate -s" implies setting the time - not slowly adjusting it. Even if you discount this example, I have a strong sense that there are many other high-level events (e.g. the network and printer examples).

What exactly is the "native notification logic"? (Note that many events are application layer).

Also, I'm not saying systemd needs eventing logic. I'm asking whether it makes sense to try solve these problems in a init process, external to applications. (for value of apps that includes those that would be started by it).

In short I'm asking whether actually its user-space that needs fixing to cope with differences in and changes to environmental state? Because it seems that doing that correctly would allow a not-too-fancy init to fire off apps in parallel and not worry about dependencies, as you argue systemd should be able to do with good apps. It seems applications will have to be modified to do this anyway, to get best effect from systemd.