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

Posted May 31, 2010 23:34 UTC (Mon) by nix (subscriber, #2304)
In reply to: The answers are there, you just don't want to admit they are right answers... by paulj
Parent article: The road forward for systemd

'network available' and 'name resolution service available' are handled by blocking the network socket of discourse until the service *is* available, by opening the socket but not accept()ing on it until the child is started. (It remains slightly unclear to me how you can fd-pass the socket fd to the child without hacking the child to accept a passed-in fd, which most unmodified daemons cannot accept -- in fact I'm not sure I've ever seen one which can.)

'System time may now be considered stable' I have no idea how you could handle. Lennart?

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) [Link] (3 responses)

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.

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

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

I don't think that "System time may now be considered stable" is a valid, or relevant or necessary event.

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

Posted Jun 2, 2010 7:38 UTC (Wed) by Darkmere (subscriber, #53695) [Link] (1 responses)

Case in hand, several of our machines run without bios batteries (concious decision) and are reset to "plate" state if they boot up. This means dates set at somewhere in 2002. Early part bootup scripts check the time of /etc/init.d, and sets local time to modification date of init.d + 15s. This is done wether or not we have a working clock for consistency. At this point, if time is right, we break it, if it's wrong, we break it. All to enforce consistency and make sure we recover from the error.

After network is established, time is then fast-forwarded to "real" time via ntpdate.

This means you have 2 distinct time-jumps. The first one is to avoid the annoyingly bad fsck times when a filesystem is 480+ days out of fsck ( right.) the second one _has_ to run before dovecot, which will detect time warp and decide "Life is bad, hardware broken, we die now" and block. ( doesn't properly shut down, just stops working properly )

So, yes. A few services, mostly mailservices, and some other ones do not like it when time changes too much. ntp itself _requires_ ntpdate early on, or it will simply decide that the time is too much out of sync to even bother adjusting it. And with large timedrifts, ntp isn't fun anyhow.

So, You may consider those services that require proper timekeeping to be broken ( perhaps they are ) but they are common and have to be managed with. And it's easier to deal with that than to deal with other situations.

Annoying time based fsck

Posted Jun 9, 2010 12:37 UTC (Wed) by hackerb9 (guest, #21928) [Link]

This means you have 2 distinct time-jumps. The first one is to avoid the annoyingly bad fsck times when a filesystem is 480+ days out of fsck ( right.)

I realize I'm going far off-topic by not contributing to the init flame war and instead giving a small helpful hint. Please forgive me. Don't jump your clock just to avoid fsck. If you're going to skip regular fscks anyway, you can use tune2fs -i 0 /dev/sdaX to disable the time based fsck.

ObligatoryFlameContribution: "NO! If you had read my blog post you'd realize you are ALL wrong! Using Makefiles for RC dependency is the one true way!