| |||||||||||||
The road forward for systemdThe road forward for systemdPosted May 26, 2010 17:37 UTC (Wed) by clugstj (subscriber, #4020)Parent article: The road forward for systemd
"Rather than concern itself with dependencies, it simply creates the sockets that system daemons will use to communicate with their clients. When a connection request arrives on a specific socket, the associated daemon will be started."
So, we are back to the "inetd" interface? That's so '80s.
Not everything that runs is accessed as a network service. What about "ntpd"?
(Log in to post comments)
The road forward for systemd Posted May 26, 2010 17:53 UTC (Wed) by tkreagan (subscriber, #4548) [Link]
That's a good question, but I think you are missing the point and should re-read the charter documents.
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.
The road forward for systemd Posted May 26, 2010 18:10 UTC (Wed) by spaetz (subscriber, #32870) [Link]
Still, I have a hard time understanding how this system is different from inetd for socket based servers. Running your sshd server via xinetd rather than systemd has been possible for ages (that was one of the examples in the original LWN article about this, I believe).
And as for cups, isn't one of its "features" (that I don't use) to announce itself to the world (and all those avahi services) as soon as the computer runs? In that case cups needs to be active anyway and not only when I actually try to access it. How is that taken care of?
The road forward for systemd Posted May 26, 2010 18:36 UTC (Wed) by mezcalero (subscriber, #45103) [Link]
please read the original article, it explains all that in detail. first read, then comment!
inetd's focus was on on-demand loading of internet services. in systemd we use socket activation as a tool to maximize parallelization, and for minimizing the need to denote the dependencies of (mostly, but not exclusively) local services.
The road forward for systemd Posted May 26, 2010 18:54 UTC (Wed) by smurf (subscriber, #17840) [Link]
I beg to differ. Upstart's idea is "run everything as soon as possible" (i.e. when its dependencies are fulfilled). That may thrash the hard disk a bit if too many of them fight over blocks of code, but then that's what the boot-time ureadahead job is for.
On the other hand, systemd's idea is "run everything only when needed". That is a net win only when most things are in fact not neded at system startup, if at all.
Personally, I tend to not install background programs that I don't need in the first place, so the second way doesn't hold much appeal for me. Moreover, some services have requirements that are a bit more involved than "listen on a TCP or UDP socket (or two)".
The road forward for systemd Posted May 26, 2010 19:12 UTC (Wed) by nirbheek (subscriber, #54111) [Link]
I honestly think you might need to re-read the original article[1]. It's very long, yes, but worth a read (especially if you want to debate it's design).
Specifically, "Parallelizing Socket Services" will show how systemd actually short-circuits the service dependency list using early socket creation to get things to start even *earlier*.
The "start things only when needed" behaviour is *after boot*, not during it[2].
1. http://0pointer.de/blog/projects/systemd.html
The road forward for systemd Posted May 26, 2010 21:53 UTC (Wed) by Tobu (subscriber, #24111) [Link] The article doesn't explain how that big list of all daemons to start in parallel is established. Either implicit dependencies are used, and you rely on socket activation, but you don't start daemons as early as they could be; or explicit dependencies are used, sockets are used only to help processes wait for each other, and the dependencies list needs to be maintained. There's an ease-of-maintainance / performance tradeoff here, and you don't get both for free.
The road forward for systemd Posted May 27, 2010 6:37 UTC (Thu) by dmk (subscriber, #50141) [Link]
Actually the article does explain this in the section "Putting it All Together: systemd".
There are different types of entities systemd is aware of.
A daemon then connects to a socket, and systemd blocks that connection until the corresponding service is started and then hands off the socket to that daemon (there comes the patching into play).
So there is no big list needed at all.
Cheers,
The road forward for systemd Posted May 27, 2010 9:58 UTC (Thu) by Tobu (subscriber, #24111) [Link] I have RTFA (thanks for the precise quote), and I don't think you get my point. You have three services: A, B, and C. C depends on B, B depends on A. The user wants C started. systemd can rely on socket activation only; it starts C, then B by socket activation, then A by socket activation. Socket activation is convenient because you don't have to declare dependencies. But it is no faster than what upstart would do; upstart would start A, wait for the A-listening event, start B, wait for B-listening event, start C. Or systemd can have the dependencies encoded; in which case, when C is requested, systemd will know to start A, B and C simultaneously, and the services will block on each other's sockets. This is faster, but you do need to do the work of writing down the dependencies. So systemd can be faster or easier than other inits. This is not bad at all; one just can't claim that systemd is both faster and dependency-agnostic.
The road forward for systemd Posted May 27, 2010 11:34 UTC (Thu) by dmk (subscriber, #50141) [Link]
Yeah sorry, i didn't pay enough attention, it seems.
Anyway, systemd doesn't encode the dependencies, as far as I understand. So it's advantage over upstart is, that it is faster only, because it does not wait for the full service to start.
A starts up until it reads from socket B (which blocks A).
Now either A got unblocked by now, in which case the new scheme is faster, because A can continue even if B isn't startet fully up already,
Does this make any sense?
The road forward for systemd Posted May 27, 2010 11:48 UTC (Thu) by dmk (subscriber, #50141) [Link]
ah, and of course, you probably can specify which services you want to start upon system boot. in which case they get started parallel and only block on each other (worst case) until the slowest system-service has read from it's socket.
So you are right, there is a list of services to start.
The road forward for systemd Posted May 27, 2010 13:06 UTC (Thu) by Tobu (subscriber, #24111) [Link] Yes. There are a few way to declare dependencies, some that allow the runtimes to overlap. Here is a good explanation. There ought to be a way to record which service triggers socket activation and use it to help write dependencies, someone should write that.
The road forward for systemd Posted May 31, 2010 15:51 UTC (Mon) by mezcalero (subscriber, #45103) [Link]
Yes, we already thought about a way to save the set of started services after boot-up to make the next boot-up even faster. We'll have to play around with this and if it is worth it for perfomance improvements it might bring.
The road forward for systemd Posted May 31, 2010 15:49 UTC (Mon) by mezcalero (subscriber, #45103) [Link]
Well, the idea is that services that are anyway required during boot-up are started in one big step, without waiting until they are actually used.
Example: we know that syslog is used by almost all services, hence we start it right-away, and don't wait until somebody actually connects to it.
Also, we distinguish ordering and requirement dependencies. So if you have a service A and one that is needed by it B and neither of them are really needed at bootup you can define a dependency of type "Requires" between them. That will then have the effect that both are started at the same time if they are requested, and the ordering is then again handled by the socket activation logic/the kernel.
So, to make this clear, and repeating what the original blog story explained: we support dependencies just fine, though for the usual services you won't need them. They will be necessary only for a few selected services, in particular a few ones that are needed during early boot-up and late shut-down.
Why it's so hard to understand? Posted May 27, 2010 7:28 UTC (Thu) by khim (subscriber, #9252) [Link] I've had this discussion so many times and I still can't believe people are thinking like that. Guys, OR and XOR are different operations! Please open the logic textbook and read about difference between them! This is vital if you want to talk about systemd! Either implicit dependencies are used, and you rely on socket activation, but you don't start daemons as early as they could be This perfect illustration: systemd can do A or B, ok, but since if you do A (but don't do B) you need to do this and if you do B (but not do A) you need to do that - and you so are doing neither this nor that so how can that work? Of course in reality systemd can do "A (activate service via socket) or B (start services from the list) and that means it can do A and B simultaneously! Terrific, uber-uncomprehensible idea, isn't it? Implicit dependencies are used and you start daemons as early as possible (i.e.: you start all daemons in parallel). If daemon A needs deamon B it does not mean daemon B should be started earlier - it means daemon A will start first and then will wait for daemon B activation. This will start the system in fastest time possible. It's all explained in original paper. I know, I know, majority of population can not even imagine OR operation and only think about XOR (they call it OR, of course) - but these people shouldn't discuss design of systemd, that's all.
Why it's so hard to understand? Posted May 29, 2010 0:25 UTC (Sat) by baldridgeec (guest, #55283) [Link] I've had this discussion so many times and I still can't believe people are thinking like that. Guys, OR and XOR are different operations! Please open the logic textbook and read about difference between them! This is vital if you want to talk about systemd!Either implicit dependencies are used, and you rely on socket activation, but you don't start daemons as early as they could be I haven't done enough thought experiments or study of the init process limitations to have any kind of coherent input about systemd's particulars (despite having read Lennart's blog post with interest last week), but I do have a rather decent knowledge of linguistics in general, and English in particular. "Either" is a word which introduces a parameter to the conditional expressed by "or." It is a flag which notifies the reader that the first and second clauses of the conditional are mutually exclusive. In other words: ("OR" != "XOR") == 1
but also
("XOR" == "Either..or") == 1
Why it's so hard to understand? Posted Jun 4, 2010 23:37 UTC (Fri) by Wol (guest, #4433) [Link]
"Either" (in normal English usage) does *not* imply the two sides of the "or" are exclusive.
"You can borrow my car if you do either A or B" - in other words I don't care which you do and you could do both if you wish. "either" is a filler word which implies "xor" but doesn't require it. If you *really* mean XOR, you have to say "either but not both".
Cheers,
Why it's so hard to understand? Posted May 29, 2010 0:30 UTC (Sat) by baldridgeec (guest, #55283) [Link]
I just re-read your post and I think I misunderstood it the first time.
Sorry for the pedantic tone in my previous comment! I guess I get a thrill from taking the wind out of grammar Nazis' sails when they're wrong, but you were addressing a different concern (and you're correct, as far as I understand the process.)
The road forward for systemd Posted May 31, 2010 15:43 UTC (Mon) by mezcalero (subscriber, #45103) [Link]
In systemd, there are two well-known boot targets: graphical.target and multi-user.target. Every service that shall be started by default is installed as a "Wants" type dependency of either one of these two targets. And when we boot up we simply collect these dependencies and start them all in parallel, in a single transaction.
The road forward for systemd Posted May 27, 2010 6:39 UTC (Thu) by tzafrir (subscriber, #11501) [Link]
Sockets are not only over IPv[46]. They may also be unix-domain ones. Syslog is one.
Care to give an example of a service/daemon that is needed before something connects through a socket? One example was given already: ntpd. It needs to start synchronizing the system regardless of anyone asking for it. But generally this is not the common case.
Also read the blog post (There, I said it myself ;-) ) regarding automounts. Those handle a different class of "services" (as someone mentioned here: get /usr or /home mounted when it's needed. A /usr mount point is the main reason for the "$remote_fs" LSB dependency).
The road forward for systemd Posted May 27, 2010 7:32 UTC (Thu) by fperrin (guest, #61941) [Link] Care to give an example of a service/daemon that is needed before something connects through a socket? One example was given already: ntpd. It needs to start synchronizing the system regardless of anyone asking for it. But generally this is not the common case.Looking at the ones currently started on my server...
The road forward for systemd Posted May 27, 2010 9:12 UTC (Thu) by marcH (subscriber, #57642) [Link]
> emacs daemon (well, it does create a socket used by emacsclient, but the entire point of emacs daemon is to launch emacs before it is actually needed)
Yes, the main (not entire) point of the emacs daemon is save startup time. Saving startup time every time except for the first time looks good enough to me. Especially if this gets me logged in faster.
The road forward for systemd Posted May 27, 2010 15:12 UTC (Thu) by drag (subscriber, #31333) [Link]
There are also a number of services that need to broadcast their avialability over the network or perform actions before they become usable.
Examples:
SAMBA -- Needs to scan network for services/system names, advertise availability and whatnot. Depends on configuration, of course.
Avahi -- Needs to advertise avialability over network. Used for MDNS
Firefly Server --- Service used Avahi to advertise avialability for DAAP service, but it needs to be able to scan the */Music directory for the server to check for updates and whatnot.
Mythtv-Backend --- Needs to configure hardware, scheduale recordings, and it advertises avialability over uPNP for clients and for media extenders.
MediaTomb -- Advertises over uPNP and needs to scan storage.
Libvirt -- It depends on configuration... if it's configured to launch a VM on boot-up then it'll need to be started on it's own, if it's not then the socket-connect method would work.
Nowadays we have a lot of Zeroconfig-type stuff available. SMB/Windows print services, Multicast DNS, UPNP, and 'Bonjuer' (Avahi). Avahi can take care of most of it for Linux/OS X networks (all the service needs to do is register with Avahi for the most part), but for Windows each uPNP service advertises on it's own stuff.
So, basically, there is a lots of different services that need to be started up and shutdown based on network availability and other circumstances.
The road forward for systemd Posted May 31, 2010 15:57 UTC (Mon) by mezcalero (subscriber, #45103) [Link]
Not sure what this list is about, but I want to mention here that it is my plan to patch Avahi so that the static service definition files you can drop in /etc/avahi/services can be bound to a systemd service. That way you can easily make an mDNS/DNS-SD service available on the network without having it running all the time.
The road forward for systemd Posted May 31, 2010 15:54 UTC (Mon) by mezcalero (subscriber, #45103) [Link]
Well, NTP tends to slowly adjust the clock to the right time instead of making it jump. I don't think there is any realistic need for making clients wait until the time is fully adjusted, because that could take minutes.
The road forward for systemd Posted May 31, 2010 15:40 UTC (Mon) by mezcalero (subscriber, #45103) [Link]
Well, if you say that Upstart runs "everything as soon as possible", then systemd runs then even sooner.
And no, systemd is about "run everything only when needed". You are missing the point. systemd is *not* about lazy-loading daemons. We can do that too, but that misses the point. We use the socket-based activation to maximize parallelization and to make dependency information unnecessary. Please read the story again to understand this!
The road forward for systemd Posted May 31, 2010 15:55 UTC (Mon) by mezcalero (subscriber, #45103) [Link]
Oops, I wanted to say "And no, systemd is *not* about..."
The road forward for systemd Posted May 26, 2010 19:30 UTC (Wed) by clugstj (subscriber, #4020) [Link]
My point is that using "inetd"'s mechanism is not new or novel (or even taken from MacOS). It is much older. I'm not saying it's a bad idea, just that it is most certainly not new - as this LWN article seems (to me) to imply.
The road forward for systemd Posted May 27, 2010 4:27 UTC (Thu) by elanthis (guest, #6227) [Link]
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 (subscriber, #57357) [Link]
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] 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: inetd does the following: systemd does the following: 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 (subscriber, #32870) [Link]
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:
I agree with init, but doesn't upstart support parallel starting? So upstart might rather:
Am I wrong here?
> inetd does the following:
> systemd does the following:
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 (subscriber, #32870) [Link] > 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: 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] 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.
The road forward for systemd Posted May 26, 2010 19:39 UTC (Wed) by zander76 (guest, #6889) [Link]
Inetd handled getting all packets and passed it to a server for execution. At the end of that execution the process would stop. This would only catch the first package and start the real service running. Its similar to lazy loading in programming.
The road forward for systemd Posted May 26, 2010 21:11 UTC (Wed) by spaetz (subscriber, #32870) [Link]
From Lennarts blog:
> That meant that for each connection a new process was spawned and initialized,
Inetd is not just for restarting lazily on every new connection it can be used to lazily start on first use and continue running. Which seems to be exactly what systemd also proposes. I know people are going to tell me to read Lennarts blog, I still fail to see how an upstart/inetd combo can't basically achieve most of what systemd achieves. But I might just be dense there. I'll wait for the dust to settle and happily use whatever makes my box boot up...
The road forward for systemd Posted May 26, 2010 22:54 UTC (Wed) by mezcalero (subscriber, #45103) [Link]
inetd was designed to lazy-load daemons. while you can also lazy-load daemons like this in systemd the main points why we want the socket based activation is that we can parallelize bootup and not have to manually configure dependenciea:
we can start syslog and dbus and avahi at the exact same time, even though avahi needs both syslog and dbus, and dbus needs syslog too. because the kernel will queue the requests, and at no time the sockets will be inaccessible, and the kernel will do all the ordering for aus for free. if dbus sends something to syslog, then that data will be buffered in the kernel socket buffer and delivered only when syslog is ready to process it. and until that time dbus can already go on and do other thinga, without having to wait for syslog to startup.
syslog, dbus, avahi work with af_unix sockets, which were out-of-scope for classic inetd.
so, let me stress again: everybody who claims that systemd was about lazy-loading daemons didnt understand the idea. systemd is about utilizing the socket logic to maximize what we can parallelize, and minimize the amount of dependencies that need to be configured.
and all of this you find explained in the blog story. its just noise i have to repeat that here.
The road forward for systemd Posted May 27, 2010 0:10 UTC (Thu) by dbenamy (subscriber, #39458) [Link]
I've read the whole blog post and your comments and I'm not sure I understand how you're answering the question. Sure inetd and systemd have different intended purposes, but that doesn't mean the mechanism isn't the same. I guess I'm wondering, is there any difference between the socket portion of systemd and running inetd early at boot to manage all the services mentioned with it's "keep the daemon running" mode?
The road forward for systemd Posted May 27, 2010 6:39 UTC (Thu) by mezcalero (subscriber, #45103) [Link]
ok, here's another try to explain this. in systemd there are three phases:
1. we set up all sockets, af_inet and af_unix.
in inetd you only have the first step, and it is mostly about af_inet, not af_unix.
(this is a a simplification btw, its a bit more complex in reality.)
this is explained in the "parallelizing socket services" part of the original blog post.
The road forward for systemd Posted May 27, 2010 14:07 UTC (Thu) by BenHutchings (subscriber, #37955) [Link]
How do you decide the necessary backlog length for listening sockets?
The road forward for systemd Posted May 28, 2010 9:31 UTC (Fri) by liljencrantz (subscriber, #28458) [Link]
I don't think you can set that manually, the kernel does that for you.
The road forward for systemd Posted May 28, 2010 10:23 UTC (Fri) by michich (subscriber, #17902) [Link] No, the backlog length must be set by userspace when making the socket listen, see
The road forward for systemd Posted May 28, 2010 10:33 UTC (Fri) by michich (subscriber, #17902) [Link] Looking at the code... It uses SOMAXCONN by default (src/socket.c:socket_init()) and it allows overriding it in the config file with a Backlog=... line (src/load-fragment.c).
The road forward for systemd Posted May 31, 2010 16:11 UTC (Mon) by mezcalero (subscriber, #45103) [Link]
As already pointed out we set it to SOMAXCONN by default, which should be a very good value for (almost?) all cases. And to cover other cases, we allow you to override that in the .socket file.
The road forward for systemd Posted May 27, 2010 0:05 UTC (Thu) by neilbrown (subscriber, #359) [Link]
> Not everything that runs is accessed as a network service. What about "ntpd"?
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.
The road forward for systemd Posted May 27, 2010 11:39 UTC (Thu) by Trelane (subscriber, #56877) [Link]
"We cannot really make "gettimeofday" block until ntpd has affirmed that the system time is correct."
Yes, especially since many computers (e.g. laptops) aren't always on the network!
The road forward for systemd Posted May 27, 2010 13:27 UTC (Thu) by marcH (subscriber, #57642) [Link]
> ntpd is an interesting one.
I understand that ntpd is different. I do not yet see how it is interesting.
ntpd is different because it has to be always started whatever happens elsewhere. Surely systemd also caters for such "no-deps", no-brainer cases.
> We cannot really make "gettimeofday" block until ntpd has affirmed that the system time is correct.
And "we" never did, and systemd does not plan to (or does it?!)
So what difference could systemd make with respect to ntpd?
The road forward for systemd Posted May 27, 2010 21:34 UTC (Thu) by neilbrown (subscriber, #359) [Link]
It is conceivable that someone might want to ensure that ntpdate runs to set the system time correctly before any NFS filesystems are mounted. Running 'make' across NFS can cause issues of times are not reasonably synchronised.
It is not clear to me that systemd allows you to specify this dependency as NFS mounts would all be done on-demand.
Whether or not this is a real issue I cannot say, but I think that from a theoretical standpoint it is at least interesting in that there could be a dependency between an on-demand service, and a service which cannot be demanded (if that makes sense).
|
|||||||||||||