Weekly Edition
Return to the Front page
| |||||||||||||
The road forward for systemd
At the end of April, Lennart Poettering announced the
initial availability of systemd, a new system initialization and session
management daemon. This announcement caused a bit of surprise and concern
for those who didn't know it was coming. Lennart's work with PulseAudio
remains a bit of a difficult memory for some users (though it seems to be
working well for most people now), and some people had thought that the
initialization
problem was solved with the growing adoption of upstart. Systemd is a
different approach, though, which may yet prove sufficiently compelling to
motivate another big change.
There are many new features in systemd, but the core change is a concept stolen from the MacOS launchd daemon - and from others that came before launchd. There are (at least) two ways to ensure that a service is available when it is needed: (1) try to keep track of all other services which may need it and be sure to start things in the right order, or (2) just wait until somebody tries to connect to the service and start it on demand. Traditional Linux init systems - and upstart too - use the first approach. Systemd, instead, goes for the second. 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. This approach simplifies the system configuration process because there is no longer any need to worry about dependencies between services. It holds out the promise of a faster bootstrap process because nothing is started before it is actually needed (plus a fair amount of other work has been done to improve boot time). The systemd approach to managing daemons allows a fair amount of boilerplate code to be removed, at least under the difficult assumption that the daemon no longer needs to work with other initialization systems. Lennart clearly thinks that it is a better way to manage system processes, and a number of others seem to agree. That said, there are some obstacles to the widespread adoption of systemd by distributors. To begin with, a number of them are just now beginning to use upstart in its native mode; the idea of jumping into another transition is not necessarily all that appealing. Daemons must be patched to work optimally with systemd; otherwise the socket-based activation scheme is not available. The patching is a relatively simple task, but it must be done with a number of daemons and the result accepted back upstream. There are also concerns about how well some types of services (CUPS was mentioned) will work under systemd, but Lennart seems to think there will not be troubles there. Another area of concern, strangely enough, is the use of control groups (cgroups) by systemd. Cgroups are a Linux-specific feature initially created for use with containers; they allow the grouping of processes under the control of one or more modules which can restrict their behavior. Systemd uses cgroups to track daemon processes that it has created; they allow these processes to be monitored even if they use the familiar daemon tricks for detaching themselves from their parents. So if systemd is told to shut down Apache, it can do a thorough job of it - even to the point of cleaning up leftovers of rogue CGI scripts and such. Cgroups would also make it easy for system administrators to set up specialized sandboxes for daemons to run in. The problem there is that there is no easy way for systemd to pick up a cgroup setup already created by somebody else; there is no transparent inheritance for cgroups now. So Lennart is asking for that type of inheritance to be added. Beyond that, though, some people have concerns about the use of cgroups in the first place. Peter Zijlstra worries about adding yet another feature which must be built into the kernel for the system to even boot. The Debian community does not like the use of the "debug" group, which is not currently configured into its kernels. Systemd may eventually get a more appropriately-named cgroup subsystem for its use, but it is not going to work without the cgroup feature at all. So people wanting to boot systems with systemd will need to have cgroups built in. Lennart has this message for people who don't like that:
Next time something is added to the kernel please mark it as "Hey,
please don't use it, this is only here so that you don't use
it. Thanks!" Maybe then dumb-ass folks like me will notice and
refrain from using it.
There are also claims that work on systemd is primarily motivated by antipathy toward Ubuntu and, especially, its copyright assignment policies. There can only be a bit of truth in some of that; hearing early talk about the work which became systemd is part of what inspired this article on assignment policies back in October. That said, Lennart insists that the motivations behind systemd are technical, and he asks that it be judged on its technical merits. So where do things stand with regard to adoption of systemd?
So it is not clear that any distribution will make the jump to systemd. But, then, even the above is a fair amount of attention for a project which has been public for less than one month. This program has reopened the discussion on how our systems should initialize themselves, and things may go on from there: there is talk of using systemd to take over the tasks of processes like cron and gnome-session. Regardless of who ends up running systemd, the ideas it expresses are likely to influence development for some time. (Log in to post comments)
The road forward for systemd Posted May 26, 2010 16:59 UTC (Wed) by dhaval.giani (subscriber, #45724) [Link]
note, systemd no longer requires the debug subsystem. With libcgroup v0.36, we now have support for named hierarchies which is what systemd exploits.
The road forward for systemd Posted May 26, 2010 17:00 UTC (Wed) by jch (guest, #51929) [Link]
I think there's a more fundamental difference between upstart and systemd, which the article hasn't mentioned. In upstart, the basic concept is the event; system states are encoded using events, such as "networking started" and "networking stopped". In startd, states are a built-in notion, which complicates the systemd code but simplifies system management.
> Daemons must be patched to work optimally with systemd
Am I right in understanding that they don't actually /need/ to be patched, as long as they can be kept from forking? (In other words -- if it works with runit and upstart, it will work with systemd.)
--jch
Patching daemons Posted May 26, 2010 17:05 UTC (Wed) by corbet (editor, #1) [Link] Daemons do not need to be patched; they don't even need to be kept from forking. The use of the word "optimally" was intentional; if you want to use the launchd-inspired mechanism, you need a patched daemon.
Patching daemons Posted May 26, 2010 17:37 UTC (Wed) by mezcalero (guest, #45103) [Link]
btw, as a side note. I finished patching all daemons we start by default on f13 now plus a few more, and the patches should have upstreamable quality.
The road forward for systemd Posted May 26, 2010 18:39 UTC (Wed) by smurf (subscriber, #17840) [Link]
You can treat "somebody wants to connect to port 3306" as an event which should trigger starting mysqld. (Assuming that somebody is going to add appropriate code to upstart.)
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 road forward for systemd Posted May 26, 2010 23:58 UTC (Wed) by Tobu (subscriber, #24111) [Link] > 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. Indeed. A getty service, screen, and systemd do not mix (nabbed from irc). getty is started, user logs in and starts screen, detaches it. Now the cgroup isn't empty and getty won't respawn. Respawning getty with a new cgroup without waiting for the cgroup to empty would work better. A service offering screen sessions with new cgroups would also work, requiring the user to explicitly use those.
The road forward for systemd Posted May 27, 2010 6:45 UTC (Thu) by mezcalero (guest, #45103) [Link]
well this is just nonsense. the screen/getty problem does not exist, scott is just a little confused about this.
not only every service, but also every user gets its own cgroup in the systemd model. if you monitor services via cgroups it doesnt mean you would stop monitoring it via the traditional sigchld stuff.
The road forward for systemd Posted May 27, 2010 11:04 UTC (Thu) by liljencrantz (subscriber, #28458) [Link]
Lennart, I've read your blog post, this article and the comments on both. I think I've wrapped my head around most of it, could you just confirm that my understanding is correct on these points?
* [x]inetd only allows you to load services either lazily (start service when first needed) or on demand (start service once per request). Systemd has a third option, to load a service at systemd startup, right after all sockets have been created. This third option is probably the one that will be used the most.
The road forward for systemd Posted May 31, 2010 15:29 UTC (Mon) by mezcalero (guest, #45103) [Link]
1. Well, I wouldn't use the terms "lazily" and "on demand" like this (they are completely synonymous in my understanding). But yes, inetd supports one-instance-per-connection and one-instance-for-all-connections modes. And so does systemd.
2. Yes, we currently handle socket-triggered, bus-triggered, file-triggered, mount-triggered, automount-triggered, device-triggered, swap-triggered, timer-triggered and service-triggered activation. And the socket-based activation not only covers AF_INET and AF_INET6, but also AF_UNIX and classic named file system fifos. And the sockets can do all of SOCK_STREAM, SOCK_DGRAM and SOCK_SEQPACKET.
3. Of course, systemd can restart daemons for you just fine. And it does so out-of-the-box for many of them (such as the gettys). Restarting a service is a core part of process babysitting. And systemd is really good at that.
4. There is dependency checking for the order. However we always say that the shutdown ordering is identical to the reversed startup ordering. Hence you may not independently configure startup and shutdown ordering. Of course manual ordering of this is not necessary when socket/bus-based activation is used.
5. No, in either way the patch is trivial, if launchd is already supported it is a bit shorter even. For the 10 daemons (or so) in the F13 default install no took more than 10 or 20 lines of changing.
6. Even if you define no native services, and rely exclusively on SysV services boot-up will be a bit faster than in classic F13 (as an example), since we make use of the parallelization information from the LSB headers (if they are available). Some other distributions (Suse) use that informaton even on classic sysv. Ubuntu does not.
7. And no, I see no problem here. The DNS timeout is 30s or so on most systems. If a DNS server really needs that much time to start up then it is definitely broken. (A simple work-around is to edit the .service file of the client service and add a After= line for your super-slow service.) But anyway, this problem is hypothetical.
8. Well, if you want to connect to a socket service you need to know its address. This has always been like that, and is not changed in any way if systemd comes into play.
9. Sure, Upstart could do that. Not sure though how that fits into their current scheme. I mean, you can hack an emacs clone into the Linux kernel if you want to. There's nothing preventing you from doing that, either.
The road forward for systemd Posted Jun 1, 2010 23:01 UTC (Tue) by liljencrantz (subscriber, #28458) [Link]
Thanks for clarifying.
The road forward for systemd Posted May 27, 2010 11:17 UTC (Thu) by Tobu (subscriber, #24111) [Link] Using sigchld certainly works, I think it's a good idea to have systemd be flexible on that. Counting a cgroup empty when it has non-empty sub-cgroups (the tty group still having a tty+user subgroup) might also do, if that's what you were getting at.
The road forward for systemd Posted May 31, 2010 15:03 UTC (Mon) by mezcalero (guest, #45103) [Link]
Well, I don't think MySQL makes a good example, since it is mostly relevant for servers, where quick bootup is not essential. We should focus on speeding up startup of desktops/laptops, not so much servers.
The road forward for systemd Posted May 26, 2010 19:01 UTC (Wed) by ghigo (guest, #5297) [Link]
I like the idea behind systemd: to start the service only (and if) they are needed. It is not only a speed gains, but also a resource gain: if a service is not required, it will not be started.
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.
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).
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.
The road forward for systemd Posted May 26, 2010 19:19 UTC (Wed) by mezcalero (guest, #45103) [Link]
hey, you haven't read the original blog story. please do. it should tell you why xinetd is a very different beat from systemd.
i really wish people would read the blog story before commenting here. many of the issues raised again and agin are already explained there in detail.
The road forward for systemd Posted May 27, 2010 7:50 UTC (Thu) by ghigo (guest, #5297) [Link]
I read the blog. In fact the author says:
<cite> The idea is actually even older than launchd. Prior to launchd the venerable inetd worked much like this: sockets were centrally created in a daemon that would start the actual service daemons passing the socket file descriptors during exec(). However the focus of inetd certainly wasn't local services, but Internet services (although later reimplementations supported AF_UNIX sockets, too). It also wasn't a tool to parallelize boot-up or even useful for getting implicit dependencies right. </cite>
I wrote that systemd is more powerful than (x)inetd, but the concept is the same.
The road forward for systemd Posted May 27, 2010 8:04 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
You are replying to the same author of the blog post and developer of systemd, FYI.
The road forward for systemd Posted May 31, 2010 15:34 UTC (Mon) by mezcalero (guest, #45103) [Link]
I am the author of the blog story. And there I try to make clear that systemd is substantially more then inetd. inetd is for lazy-loading services. systemd uses the same technique but does so to parallelize boot-up and make dependency information redundant.
So, please, don't compare systemd with inetd too much, because that misses the core point.
If you don't see what the difference between systemd and inetd is, then please read the story again, particularly the part about "Parallelizing Socket Services".
The road forward for systemd Posted May 27, 2010 8:37 UTC (Thu) by marcH (guest, #57642) [Link]
> 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.
Lucky you.
The road forward for systemd Posted May 27, 2010 9:04 UTC (Thu) by dgm (subscriber, #49227) [Link]
Or extremely unlucky, if you think of it. My Lucid UNR takes about 30 seconds from grub to desktop. If his BIOS takes longer than that there's something definitely wrong with his machine... or he's talking about one of those servers with RAID that take forever to boot.
The road forward for systemd Posted May 27, 2010 14:41 UTC (Thu) by kronos (subscriber, #55879) [Link]
My Asus (M4A79) board has a marvel controller with it's own option BIOS, and I've added an extra PATA controller.
With Asus ExpressGate enabled (default) it takes 38 second from power on to grub... Without EG it takes "only" 26...
The road forward for systemd Posted Jun 3, 2010 7:33 UTC (Thu) by eduperez (guest, #11232) [Link]
Some RAID controllers are painfully slow, and I mean they take several minutes to initialize and start loading the boot manager.
The road forward for systemd Posted May 26, 2010 17:04 UTC (Wed) by dhaval.giani (subscriber, #45724) [Link]
Also, regarding the inheritance issue. What was happening is that some subsystems (well, ok, just cpusets), do not set default initial values, which prevent tasks from being attached to them. Since systemd cannot (and should not) control where/how cgroups are mounted, there could be failures because of cpuset. (An example case mentioned in the first mail of the thread you referred).
But, since then we have realized about the existence of named hierarchies, which handle the issue for systemd.
We still do need to take care of the cpuset default values issue (as there are other use cases), and it has not exactly proven trivial to fix it in kernel space as well :-)
The road forward for systemd Posted May 26, 2010 17:11 UTC (Wed) by alogghe (subscriber, #6661) [Link]
Systemd looks nicely done so far.
However as most of us are -users- of init systems I'm not sure that shaving a few seconds off the boot that is already getting pretty fast is that attractive (non of my systems reboot very often at all) for the further disruption of a new init system.
A key feature that would cause me to be interested in a new init system is something I've seen no awareness of in from the groups involved -
Self healing ala Monit http://mmonit.com/monit/
Here's an example from monit of what I'd like to see in an upstart or systemd configuration -
check process sshd with pidfile /var/run/sshd.pid
Monit allowed me to create bulletproof embedded systems to deploy in developing economy banks.
Most daemon issues are not caused by pids just dying in my experience.. it's when they become unresponsive to user/program interactions. None of the init replacements deal with that (including solaris as I recall).
I'd like this integrated in phone/laptop/server environments.
P.S. Lennart thanks for Pulse, it's been an awesome improvement.
The road forward for systemd Posted May 26, 2010 22:58 UTC (Wed) by mezcalero (guest, #45103) [Link]
we shouldnt lose focus here. i dont think something like monit needs to be in the init system itself, it can easily be done outside of it, and interface with it in various ways.
The road forward for systemd Posted May 28, 2010 0:29 UTC (Fri) by gerdesj (subscriber, #5446) [Link]
Sorry, I think you are wrong here.
I think that the daemon control system itself (whatever it is called) should be as intelligent as possible. If it can know that a daemon is borked and take remedial action, ie restart it sensibly until it is shown to be buggered and then give up, then great.
Even better if you could feed it rules of some sort that told it how to tell the difference between "recalcitrant" and "properly buggered".
Pretty much all systems I know of have a "status" subcommand to the service/daemon controller - why not make it actually work properly to the point where you can rely on it *completely?
Basically, would it not be nice to be able to believe your service manager when it says that Apache is fine rather than reaching for Monit/Nagios/web browser.
If the Gentoo "/etc/init.d/<service> zap" command went away then this problem is solved.
(* => for a given value of completely, which at the moment on all systems I manage (Gentoo, SLES, Fedora, *buntu, Win{lots of different versions} is local knowledge and folklore)
The road forward for systemd Posted May 28, 2010 5:27 UTC (Fri) by jrn (subscriber, #64214) [Link]
I think Lennart was suggesting it would be better to add hooks to init, and leave developing a good policy for making use of them to a separate project.
The road forward for systemd Posted Jun 5, 2010 13:29 UTC (Sat) by segedunum (guest, #60948) [Link]
> P.S. Lennart thanks for Pulse, it's been an awesome improvement.
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 road forward for systemd Posted Jun 7, 2010 11:58 UTC (Mon) by nye (guest, #51576) [Link]
>PulseAudio is the reason I run a Mac. Seriously.
And the reason I run Windows, in fact.
The road forward for systemd Posted Jun 7, 2010 13:15 UTC (Mon) by anselm (subscriber, #2796) [Link] The only reason? IMHO this amounts to cutting off one's nose to spite one's face. It is after all quite possible to run Linux on a workstation without PulseAudio. I do, for example (on Debian sid, too), and audio still seems to work for me even so.
The road forward for systemd Posted Jun 7, 2010 16:23 UTC (Mon) by nye (guest, #51576) [Link]
Not the only reason, but the triggering reason. The thing that made me finally decide 'the people who design current desktop Linux systems have goals which are wholly incompatible with mine'.
The road forward for systemd Posted Jul 7, 2010 6:06 UTC (Wed) by Triffid (guest, #68496) [Link]
PulseAudio is terrible. I always try to rip that out first, but the distro vendors really seem to love this it. If it was up to me, I'd at least give users a choice.
Between PA and Avahi, I have had quite a few problems with stuff this guy has written. Systemd looks like another attempt to change things for no good reason.
The road forward for systemd Posted May 26, 2010 17:37 UTC (Wed) by clugstj (subscriber, #4020) [Link]
"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"?
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 (guest, #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 (guest, #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 (guest, #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 (guest, #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 (guest, #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 (guest, #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 (guest, #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 (guest, #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 (guest, #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 (guest, #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 (guest, #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 (guest, #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 (guest, #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 (guest, #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).
The road forward for systemd Posted May 26, 2010 17:45 UTC (Wed) by ballombe (subscriber, #9523) [Link]
> The Debian community does not like the use of the "debug" group, which is not currently configured into its kernels.
There is another reason: Debian support non-Linux kernels that do not provide cgroups. Having a default init system that only support Linux is problematic.
The road forward for systemd Posted May 26, 2010 18:39 UTC (Wed) by mezcalero (guest, #45103) [Link]
well if non-linux matters for them they can just use systemd on linux and something else on the other oses.
its not different with upstart, which is linux-only, too.
The road forward for systemd Posted May 26, 2010 18:43 UTC (Wed) by aleXXX (subscriber, #2742) [Link]
Are you sure ?
What parts of upstart depend on Linux and couldn't work e.g. on FreeBSD ?
Alex
The road forward for systemd Posted May 26, 2010 22:32 UTC (Wed) by mezcalero (guest, #45103) [Link]
well, while scott and i disagree in various points we actually agree on one thing: an init system doesnt need to be portable, and portability to other systems means severely limiting how you can make use of the available functionality of the os.
or to put it more drastically: i dont believe in portability, i will not let myself be limited by that and will not work on improving the portability of my projects. that said, for other, more high-level projects than systemd i maintain where portability might be interesting and easier to do, i wont make it it particularly hard for people who care about such things. i will merge their patches if they are clean, and i will opt for the portable iface if there is the alternative, but that's where it ends.
i believe the constant call for portability from some folks is just slowing us down, to little value. I for one am interested in making Linux better, not some non-existing abstract idea of an OS.
and to answer more to the point: among other apis upstart uses cn_proc, which is very linux specific.
The road forward for systemd Posted May 26, 2010 23:49 UTC (Wed) by alankila (subscriber, #47141) [Link]
It's probably a good idea to not waste time thinking about portability, because good ideas get ported to other OSes anyway.
The road forward for systemd Posted May 27, 2010 1:29 UTC (Thu) by rsidd (subscriber, #2582) [Link]
Also, I'd guess the vast majority of FreeBSD users do not use Debian's version and do not care about upstart or systemd.
The road forward for systemd Posted May 27, 2010 2:12 UTC (Thu) by da4089 (subscriber, #1195) [Link]
Personally, I'd guess the vast majority of Debian users do not care about upstart or systemd.
I find the recent application of so many developer hours to something that matters so little confounding.
The road forward for systemd Posted May 27, 2010 4:18 UTC (Thu) by kov (subscriber, #7423) [Link] It matters a load for me, and I am a Debian user and developer, so I find your sentence amusing.
The road forward for systemd Posted May 28, 2010 9:43 UTC (Fri) by mpr22 (subscriber, #60784) [Link]
Many people don't care about things that (a) matter and (b) affect them. That doesn't make those things not matter, or not affect them.
The road forward for systemd Posted May 26, 2010 18:06 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
Doesn't seem to be a good idea.
The whole approach of "let's just start everything and hope it works out well" is somewhat messy.
What are we going to do with network sockets and other services, for example? I have an application which bombs out if BIND is not yet started (it needs a resolver to resolve host names when it reads its config). How do I mark this dependency?
Or another thing, with upstart I can specify that my another application depends on PostgreSQL. So there's no sense in running it if Postgres is not started or is disabled. I don't want it to be stuck forever waiting for connection.
Another painful area - stopping services. I want my init system to correctly traverse and carefully deconstruct dependency graph. For example, I want my webapp to be stopped before PostgreSQL is stopped.
Upstart nicely solves all these problems. Systemd - not so much.
The road forward for systemd Posted May 26, 2010 18:18 UTC (Wed) by drago01 (subscriber, #50715) [Link]
The road forward for systemd Posted May 26, 2010 18:33 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
Care to provide even more trivial links without addressing a single line in my post?
Lennart also is misguided - target based systems are NOT good. Most of users _need_ NetworkManager to be started as soon as possible.
In essence, the goal is usually 'run everything ASAP' and not just 'run GNOME'. There are generally very little subsystems that don't need to be started on each boot.
However, sometimes we DO need to delay some service (a good example is CUPS). And that's where his ideas might be useful.
'Involuntary confinement' with cgroups might also be useful as an optional feature in Upstart or other init systems (even in standard Sys-V-ish daemon startup scripts).
The road forward for systemd Posted May 26, 2010 18:44 UTC (Wed) by mezcalero (guest, #45103) [Link]
you have not read the blog story. please do that. then you'll see that your comments are mislead.
The road forward for systemd Posted May 26, 2010 22:51 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
Sorry, your mind-reading ability has failed you.
So go and read MY post - it contains valid objections.
The road forward for systemd Posted May 31, 2010 16:16 UTC (Mon) by mezcalero (guest, #45103) [Link]
Because if you had read it you should have understood that in fact we start all services at the same time, in one big transaction. So if you try to argue against systemd by saying things like "Most of users _need_ NetworkManager to be started as soon as possible" then it is clear that you have not understood who systemd works: because in fact we start nm much earlier than Upstart or SysV: we start it right at the same time as we also start Syslog and D-Bus.
The road forward for systemd Posted May 27, 2010 14:21 UTC (Thu) by buchanmilne (guest, #42315) [Link] Most of users _need_ NetworkManager to be started as soon as possible.AFAICT, systemd should start NetworkManager sooner, because systemd won't wait for (e.g.) messagebus to finish starting before starting NetworkManager. If there are any other D-Bus-based services that NetworkManager requires (maybe wpa_supplicant?, sorry, my distro doesn't use NetworkManager, and all network interfaces come up very early, including WiFi ...), they will also be started in parallel. This is covered in the blog post. In essence, the goal is usually 'run everything ASAP' and not just 'run GNOME'.Where do you see this goal of 'run GNOME'? It's certainly not in the systemd blog post ... However, sometimes we DO need to delay some service (a good example is CUPS)Quote from the blog post: Same for a printing system: unless the machine physically is connected to a printer, or an application wants to print something, there is no need to run a printing daemon such as CUPSDid you read the blog post?
The road forward for systemd Posted May 26, 2010 21:11 UTC (Wed) by sebas (subscriber, #51660) [Link]
To be perfectly honest, this is tiresome.
There's a number of posts in this thread that would, in my opinion, at least qualify to get a short answer, possibly referring to the full article, instead of just being brushed off like this.
Denying anybody the right to comment when the original post (which is quite lengthy indeed) hasn't been fully read, or understood might be OK from a "let's save us all time (especially myself)" point of view, but it also kills off discussions that would otherwise contribute to a better understanding of why the world needs yet another, incompatible system to start their OS. (Yes, not a given, people don't like changes without immediate, positive net effects, and rightfully so.)
More importantly, what systemd needs, especially in its early and uncertain phase of development, is awareness. You don't create that by killing off discussions, you create that by patiently explaining people what it is, does, its benefits and disadvantages. Over and over.
The road forward for systemd Posted May 27, 2010 14:34 UTC (Thu) by marcH (guest, #57642) [Link]
Yeah, it's a bit like "you haven't read Marx, how dare you talk about the Economy?"
What about a short FAQ?
Think about the "F" in "FAQ" for a minute. My guess is that this "F" must somehow be related to all these stupid people not RTFM (with a different "F").
The road forward for systemd Posted May 31, 2010 16:19 UTC (Mon) by mezcalero (guest, #45103) [Link]
Hmm, this is funny. Because the original blog story actually includes an FAQ! Have *you* read it?
The road forward for systemd Posted Jun 7, 2010 20:06 UTC (Mon) by marcH (guest, #57642) [Link]
At this time, the blog includes a mostly political (and buried) FAQ that does not answer any technical question.
This blog is light years away from being a good systemd sales pitch. That's perfectly OK as long as you do not get angry and annoying when people fail to read between its (too numerous) lines.
Just try to compare your blog to any LWN article and you might understand better the misunderstandings happening here.
The road forward for systemd Posted May 26, 2010 18:31 UTC (Wed) by mezcalero (guest, #45103) [Link]
please read the original blog post. it explains all that. first read, then comment!
The road forward for systemd Posted May 26, 2010 18:42 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
What makes you think I haven't read it? Care to point me to a place where it says something about network, for example?
Maybe, like, ability to start CUPS only if there's networking or on an on-demand request (if a client tries to connect to it)?
The road forward for systemd Posted May 26, 2010 19:07 UTC (Wed) by martin.langhoff (subscriber, #61417) [Link]
The blog post is long, but very good. Definitely answers all your questions, and the ones you'll ask afterwards.
WRT CUPS and networks, look at the posted messages after the blogpost itself, there are some interesting notes there about it.
The proof is -- as usual -- in the pudding, but the design of systemd seems good, and simplifies things a lot. If it is available for F14, I'll switch to it.
My only worry is the idea of "writing init scripts in C" -- I think it's hyperbole to indicate that you just write a config file, and a C program (systemd) does the right thing. That misses the overrides you can apply trivially in most linuxen by creating /etc/sysconf/$servicename or just hacking the damn initscript.
AIUI, you can just point systemd to an oldstyle script anyway -- that loses the parallelisation and fast-boot properties.
Maybe systemd can provide a low-overhead init script interpreter? Python? Lua? How to do it would be a challenge -- you don't want an embedded interpreter in systemd, but you don't want the startup overhead either.
The road forward for systemd Posted May 26, 2010 19:57 UTC (Wed) by jspaleta (subscriber, #50639) [Link]
The proof is indeed in the pudding. Like for most things, its much easier for me to wrap my head around it when there are bits I can break.
There's a lot of flexibility here for service control that sysadmins who have grown to rely on sysV init scripts are going to need to expend some energy learning to wrap their heads around some of the flexibility in control/resource limits that relying on cgroups allows. From a sysadmin pov, this seems like some of the richer benefits are going to be reaped in understanding that particular point of the design... as well as some of the biggest challenges. The discussion about how cgroup level interactions with screen-like detached behavior is going to be important.
-jef
The road forward for systemd Posted May 26, 2010 21:46 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
most sysadmins deal with servers, and on the servers there is less value in the delayed startup, and more importance that the first time something tries to access a service it be up and running (without having to wait for it to initialize)
this is something useful for desktops, but that's not for where most sysadmins work.
The road forward for systemd Posted May 26, 2010 22:07 UTC (Wed) by jspaleta (subscriber, #50639) [Link]
Did I say anything about boot up speed? I'm referring to how cgroup level resource controls can be configured. The follow up discussion in the blog comments about detached screen session behavior in a cgroups controlled login session speak directly to the sorts of tradeoff of the flexibility of the cgroups level controls as it applies to long running services like login sessions.
The design of systemd isn't _just_ about service start up. There are elements in there which deal with resource constraints over the lifetime of the systemd control process via its use of cgroups. I think sysadmins should attempt to wrap their heads around when cgroup level control are going to be useful..and when they are going to be..in the way. Part of that will mean getting familiar with the libcgroup utilities..which are mentioned in the blog story.
To paint systemd as just being a different way to start things up fast is missing a critical point about service management in choosing to rely on cgroups in the design.
-jef
The road forward for systemd Posted May 26, 2010 20:09 UTC (Wed) by nybble41 (subscriber, #55106) [Link]
What's wrong with including an embedded interpreter in systemd? After all, Lua is small enough that some programs use it just to parse their configuration files. It wouldn't add much overhead to handle both configuration and scripting with an embedded Lua instance.
The road forward for systemd Posted May 31, 2010 16:26 UTC (Mon) by mezcalero (guest, #45103) [Link]
Well, my point was that I claim that a full turing-complete programming language should not be necessary to start up most services. Instead we should just identify common code in the various init scripts and make them available directly in the init system via a simple option in the .service file or in the daemons themselves. I am quite sure that for a few services this will not work out we we will still need a shell script for them. But that's fine, it will then just spawn a shell script which as last step simply execs the real daemon. But again, there is really no need for a shell interpreter for the majority of services, and hence let's just get rid of it.
The road forward for systemd Posted May 31, 2010 18:21 UTC (Mon) by nix (subscriber, #2304) [Link]
Exactly. What would be worthy of disparagement was if you'd decided that we *could* no longer use shell script fragments to start services. But, really, the repetitive umpty-Kb-long shell scripts to start random daemons on current systems are just ridiculous. Most of that isn't needed to *start the daemon* at all (BSD-style boot scripts didn't need it), but to provide the other services (stop/restart, easy reconfiguration via stuff in /etc/default et al) that the distribution needs. And *that* doesn't really belong in *every single* startup script. Better to centralize it.
The road forward for systemd Posted May 26, 2010 22:49 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
Guys, I've read this blog post. Several times by now to make sure that I hadn't missed something.
I've read (most of) comments.
Still no answer. So can you just cut'n'paste the relevant passages instead of telling me to RTFBP?
The answers are there, you just don't want to admit they are right answers... Posted May 27, 2010 8:01 UTC (Thu) by khim (subscriber, #9252) [Link] I have an application which bombs out if BIND is not yet started (it needs a resolver to resolve host names when it reads its config). How do I mark this dependency? If the application bombs out before something is started then the application should be fixed - it's as easy as that. It can connect to bind (then it'll be stopped till bind is started) or we can fix the resolver library to block the application till the bind is started (exactly the same thing, but more clear solution). Or another thing, with upstart I can specify that my another application depends on PostgreSQL. So there's no sense in running it if Postgres is not started or is disabled. I don't want it to be stuck forever waiting for connection. You either need the application, or you don't need it. If you need it then start it and PostgreSQL will be started, if you don't need it then don't start it. Another painful area - stopping services. What's so painful about it? I want my init system to correctly traverse and carefully deconstruct dependency graph. For example, I want my webapp to be stopped before PostgreSQL is stopped. Your webapp will be stopped before PostgreSQL if it keeps the connection to PostgreSQL active - as it should. Look, the Unix survived for 40 years as a research project - and a lot of components are connected via ducttape and chewing gum. This is crazy. If it's production system then it should be built as production system. systemd removes the chewing gum and ducttape - and there are no way to reattach them. This means components which don't fit without ducttape must be changed to fit better, that's all. If you don't like it - you can use the old system, if you want, it's free software, after all.
The answers are there, you just don't want to admit they are right answers... Posted May 27, 2010 10:47 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
"If the application bombs out before something is started then the application should be fixed - it's as easy as that. It can connect to bind (then it'll be stopped till bind is started) or we can fix the resolver library to block the application till the bind is started (exactly the same thing, but more clear solution)."
Bombing out on unresolved hosts is a CORRECT behavior. Modifying the app so it can work with a certain init system is crazy.
So we still need to have explicit dependencies at least for SOME services.
"You either need the application, or you don't need it. If you need it then start it and PostgreSQL will be started, if you don't need it then don't start it."
And what if PostgreSQL is down because I'm upgrading it? Or maybe I don't want it to start for some reasons (like system recovery in progress, etc.)?
"What's so painful about it?"
Doing it correctly.
"Your webapp will be stopped before PostgreSQL if it keeps the connection to PostgreSQL active - as it should."
Why should it? I use a connection pool, but it doesn't keep inactive connections forever. So it might certainly be possible that the webapp doesn't have any active connections during shutdown.
"Look, the Unix survived for 40 years as a research project - and a lot of components are connected via ducttape and chewing gum. This is crazy. If it's production system then it should be built as production system. systemd removes the chewing gum and ducttape - and there are no way to reattach them. This means components which don't fit without ducttape must be changed to fit better, that's all. If you don't like it - you can use the old system, if you want, it's free software, after all."
Yes. That's why I hate shell scripting and systemd. They work in _most_ cases and can miserably fail in sometimes.
Upstart has an advantage of clean _explicit_ dependencies. They can be analyzed (with the help of systemd!) and fixed if required. But they are _explicit_.
It's all fixable... Posted May 27, 2010 11:16 UTC (Thu) by khim (subscriber, #9252) [Link] Bombing out on unresolved hosts is a CORRECT behavior. Modifying the app so it can work with a certain init system is crazy. Well, the alternative is fix in resolver library as I've pointed before. And if the application should be fixed in some other cases then it may be done with some kind of "babysitter" wrapper. So we still need to have explicit dependencies at least for SOME services. What for? So far all examples were reiterations of the same scheme: "I need the explicit dependencies because I have an application which is broken" and the obvious answer is "well, fix the application"... It can often be done with some kind of wrapper so application itself is intact... And what if PostgreSQL is down because I'm upgrading it? Or maybe I don't want it to start for some reasons (like system recovery in progress, etc.)? Then the systemd must be informed and all applications which need the PostgreSQL will wait. Why should it? I use a connection pool, but it doesn't keep inactive connections forever. So it might certainly be possible that the webapp doesn't have any active connections during shutdown. If webapp drops all active connections to PostgreSQL while it has unsaved state then it's buggy and should be fixed. If the active connections are closed because there are no work to be done with them then it does not need PostgreSQL to shut down. Yes. That's why I hate shell scripting and systemd. They work in _most_ cases and can miserably fail in sometimes. I'm yet to see the problem where systemd fails because of it's design and not because some other component is broken. Upstart has an advantage of clean _explicit_ dependencies. IMNSHO it's disadvantage. They can be analyzed (with the help of systemd!) and fixed if required. But they are _explicit_. Yup. That's why they'll never be correct. Currently dependency graph is partially stored in application code and partially in upstart configuration. This information is often stale and incorrect - but with some application of time and resources the whole system works - but it only proves the #3 truth from RFC1925. But is it correct and good approach? Obviously not - duplication of information is almost always bad because copies grow apart over time. Sometimes it's needed for performance reason, but I'm not seeing such need with regard to systemd...
It's all fixable... Posted May 27, 2010 12:03 UTC (Thu) by hppnq (guest, #14462) [Link] But is it correct and good approach? Obviously not - duplication of information is almost always bad because copies grow apart over time. Sometimes it's needed for performance reason, but I'm not seeing such need with regard to systemd... But systemd should be able to handle things like socket options, network addresses, file permissions/ownership, and a few more. I don't see how this can be easily done without duplication of information. (And how about processes that decide on, say, port numbers or domain socket names only after they have been started?)
It's all fixable... Posted May 31, 2010 16:38 UTC (Mon) by mezcalero (guest, #45103) [Link]
Yes, you can configure quite a few socket settings in the systemd .socket files. As it turns out the amount of duplication is only minimal here, since in fact most services don't play any wild games with socket options, and many can be set after the first connection attempt.
The answers are there, you just don't want to admit they are right answers... Posted May 27, 2010 14:47 UTC (Thu) by buchanmilne (guest, #42315) [Link] Bombing out on unresolved hosts is a CORRECT behavior.Depends on the app, and you haven't described it. Maybe it should be restarted when bind restarts, but then ... why does name resolution depend on a local DNS server? openvpn keeps retrying when it can't resolve, and that works just fine for me. When I have connectivity, it starts, when I don't it just retries every one in a while. Why should it? I use a connection pool, but it doesn't keep inactive connections forever. So it might certainly be possible that the webapp doesn't have any active connections during shutdown.If there aren't any active connections, there is no harm in shutting Postgresql down at the same time you shut down the web app. Upstart has an advantage of clean _explicit_ dependencies. They can be analyzed (with the help of systemd!) and fixed if required. But they are _explicit_.Note that earlier dependency-based init systems also have explicit dependencies. For example, Mandriva has used prcsys (since about 2004), which uses LSB-headers for dependency information. Funnily enough, so does systemd. Quoting from the blog post: "Note that we make use of the dependency information from the LSB init script headers, and translate those into native systemd dependencies. Side note: Upstart is unable to harvest and make use of that information."Did you read the blog post?
The answers are there, you just don't want to admit they are right answers... Posted May 27, 2010 15:10 UTC (Thu) by keybuk (subscriber, #18473) [Link]
The "unable" in that post is wrong. In fact, the code to have Upstart support LSB headers in init.d scripts as an additional source of jobs has already been contributed, and will be in the next major release.
The answers are there, you just don't want to admit they are right answers... Posted May 27, 2010 16:09 UTC (Thu) by paulj (subscriber, #341) [Link] why does name resolution depend on a local DNS server? openvpn keeps retrying when it can't resolve, and that works just fine for me. When I have connectivity, it starts, when I don't it just retries every one in a while. Ugg.. Such polling behaviour is horrid. How frequently should apps poll? No matter how slow or fast apps poll, it will be too slow for someone and it will burn energy for everyone. If systemd leads to lots of apps being modified to poll for resources then: ye gods! We surely have to get to a stage where these things are event-driven? The most common system for this seems to be DBus now. DBus already can auto-start services on demand. If we really must modify everything, why not just port to DBus? It seems a lot of apps will have to be modified to use an event posting service anyway, if they're ported to systemd, so why not skip the systemd step altogether? Just because these dependencies can be "magiced" away technically at the init level, does *not* mean they go away. They're still there, and so they're still going to have be dealt with at some level. Which may mean that all that systemd accomplishes is a boatload of pointless churn, on the path toward a userspace that's integrated around an event-driven system service (e.g. DBus). Also, I'm not looking forward to the release or 4 of instability we Fedora users no doubt will go through as all the corner cases get debugged out (systemd and updating apps).
The answers are there, you just don't want to admit they are right answers... Posted May 31, 2010 16:49 UTC (Mon) by mezcalero (guest, #45103) [Link]
You're FUDding.
There is no polling involved, the normal glibc resolver times out after 30s or so, that is more then enough time to get things started. The problem you are discussing is made up.
Clients need *not* to be patched. Servers do, but the work is minimal, and already finished for all daemons we start by default on F13.
I think you are a bit naive on the amount of coding and political work you'd need to do to make everybody use D-Bus instead of normal sockets. Also, let's not forget that there are quite a few services where D-Bus makes little sense. D-Bus is an RPC. Sockets are on a lower level. I mean, good look in arguing that glibc should now talk D-Bus when resolving DNS info.
The answers are there, you just don't want to admit they are right answers... Posted May 31, 2010 22:40 UTC (Mon) by paulj (subscriber, #341) [Link]
I'm not FUDing. I was replying to a specific example about openvpn - not systemd. And then generalising from it to *polling* - not to name resolution! I said *IF* systemd leads to more polling in apps, that would be bad.
I understand systemd does allow for basic dependencies (the fulfillment state transition of which is obv. an event). However, the stated philosophy in systemd is to eschew encoding dependencies in config files and instead have the apps just "Do The Right Thing" (whatever that may be), as much as possible.
My question then is: Doesn't this philosophy mean that, in addition to systemd managing process lifetimes, that you also need an a higher-layer event-posting system above systemd to allow apps to stay informed of event fullfilment and transitions, and handle them? Events such as "network available", "name resolution service available", "System time may now be considered stable", etc.
Basically, systemd deliberately does not answer these questions, other than that it can act as a proxy for certain services by handling their fd, correct? If so, do you agree that there would such a higher-level system? If so, why do you think it is worth having BOTH a fancy init AND a fancy higher-level event-handling system? Why not just do all the work in this fancier higher-level service, and migrate services to be started by this higher-level service, and stick with the dumb init?
You may say I'm FUDing, but none my assertions in the comment you replied were about systemd. Anything relating to systemd were in the form of questions (except perhaps my fears of instability), as with this comment, and all I'm interested in is to have my questions/concerns addressed.
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) [Link]
'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]
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 (guest, #45103) [Link]
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 (✭ supporter ✭, #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 (guest, #45103) [Link]
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]
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 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!
The answers are there, you just don't want to admit they are right answers... Posted Jun 1, 2010 11:43 UTC (Tue) by mezcalero (guest, #45103) [Link]
I am not sure why you get the idea that you need to poll for anything if systemd is used. systemd itself does not do repetitive polling anywhere, although we now can watch quite a few different kinds of resources for you: devices, file systems, automounts, sockets, paths, timers, swap files and more.
I am not sure what you mean by "basic dependencies". systemd actually has a pretty elaborate dependency system, which distinguishes eight kinds of dependencies: Requires, RequiresOverridable, Requisite, RequisiteOverridable, Wants, Conflicts, Before, After. And you can use that to build dependencies between all ten kinds of units we have.
There doesn't need to be an event for "name resolution available", because in the socket-based actviation scheme it is always available. And most services which need a live network, such as IPv6 discovery daemons, or Avahi or suchlike hook into netlink anyway to get notifications for this -- and rightly so. I see little need for another generalized eventing system. And I don't think that "System time may now be considered stable" is a valid event. On all machines built in the last 25 years or so the RTC should be "stable" from the beginning. I mean, it would be nice to have a notification system where the kernel informs us about a jumping time (i.e. on timezone changes), but that has nothing to do with the monotonic clock or systemd.
So, I fail to see why you'd want any generalized eventing system beyond the dependency system that systemd offers to you and the various notification systems the kernel already provides, such as inotify, netlink, udev, poll() on /proc/mount, and similar. If apps want those events they should use those notification facilities natively, there is little need to involve systemd in that.
Does that answer your question? Because quite frankly, I am not sure I understood the question entirely...
The answers are there, you just don't want to admit they are right answers... Posted May 27, 2010 16:32 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
"Depends on the app, and you haven't described it. Maybe it should be restarted when bind restarts, but then ... why does name resolution depend on a local DNS server? openvpn keeps retrying when it can't resolve, and that works just fine for me. When I have connectivity, it starts, when I don't it just retries every one in a while."
Because this app must work even without Internet connectivity, using only local authoritative BIND server to resolve local names.
"If there aren't any active connections, there is no harm in shutting Postgresql down at the same time you shut down the web app."
Aside from possible race conditions if app tries to connect to Postgres while Postgres is being shut down. It's especially possible if app needs to do some clean-up actions on shutdown (say, write a log entry to DB).
Unlikely? Yes. Possible? Certainly. And that's what I hate most in Unix systems.
The correct behavior in my opinion would be to explicitly mark certain dependencies as 'parallelizable' so they can be started simultaneously. You won't be able to automatically and reliably detect all dependencies, that's a fact of life.
"Note that earlier dependency-based init systems also have explicit dependencies. For example, Mandriva has used prcsys (since about 2004), which uses LSB-headers for dependency information. Funnily enough, so does systemd. Quoting from the blog post"
Yes. However, earlier init systems were rule based instead of event-based. That's a great advantage of upstart, actually. And another commenter noted that upstart can now use LSB headers.
"Did you read the blog post?"
Yes.
PS:I quite like PulseAudio precisely because it tried to cover _all_ use-cases, including piping audio over the network to a USB bluetooth handset. This project - not so much.
The answers are there, you just don't want to admit they are right answers... Posted May 27, 2010 17:06 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
BTW, Scott James Remnant posted a great article about Upstart and systemd:
http://www.netsplit.com/2010/05/27/dependency-based-event...
It also nicely clarifies distinction between event-based and rule-based startup systems.
The answers are there, you just don't want to admit they are right answers... Posted May 31, 2010 16:34 UTC (Mon) by mezcalero (guest, #45103) [Link]
You don't have to patch any client. Clients should just connect the the service they want to use, systemd cares about the rest. End of story.
You are discussing a problem that doesn't exist.
The answers are there, you just don't want to admit they are right answers... Posted May 31, 2010 16:33 UTC (Mon) by mezcalero (guest, #45103) [Link]
Well, this problem does not exist. The socket is created before bind is started, so a bind client will never notice that bind is in fact not yet started, or might still be in the process of starting up: because it can connect the socket just fine.
So, the whole idea of "application bombs out if bind is not yet started" is bogus. Doesn't exist in the systemd scheme.
The road forward for systemd Posted May 27, 2010 15:06 UTC (Thu) by buchanmilne (guest, #42315) [Link] What makes you think I haven't read it? Care to point me to a place where it says something about network, for example?Search for "AF_INET" or "IP " in the blog post. Or, you need to clarify your "question" further.
The road forward for systemd Posted May 27, 2010 16:59 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
Mention of AF_INET is not enough.
For example, what systemd is going to do if network interface required for the daemon does not go up? Or only one of two interfaces goes up?
There's just too many possibilities.
The road forward for systemd Posted May 27, 2010 18:27 UTC (Thu) by drag (subscriber, #31333) [Link]
> For example, what systemd is going to do if network interface required for the daemon does not go up? Or only one of two interfaces goes up?
Not sure.
Most network services that want to listen on multiple interfaces will just listen to 0.0.0.0 which will cause them to listen to all network interfaces regardless of the time they come up or not. In that case the service will remain dormant until somebody on any network tries to use it.
For network services that I've used that depend on different ports being open for different purposes the daemon itself just listenned on all interfaces and then only responded appropriately based on it's own internal configuration.
For example: DNSMASQ.
Dnsmasq (just so you don't have to look it up if you never used it) is a clever little daemon used to cache DNS requests and can perform DHCP services if configured. I've used it extensively for building network routers and in doing virtual machine host configurations. It's also used in things like OpenWRT for small soho routers. Very nice little application that allows me to eliminate a number of difficult-to-configure services and can read from yoru hosts file to make it simple to make contained DNS resolved network names for a small/medium sized network.
Well Dnsmasq depends on being able to use the DNS ports and DHCP ports on the internal network. Then it also needs to have the ability to do DNS requests to a external network.
Also it's common to have many multiple network ports on a router, so you can configure it to provide DHCP services to some networks, but not on others.
Now you can hard-code it to use only certain network interfaces or ip addresses, but the recommended configuration just has it listenning to DNS/DHCP requests on all networks simultaniously and it will choose to respond to it based netmasks and that sort of thing. That way you don't have to care about it... it takes care of the policies on it's own.
---------------------------------------
Otherwise what I use for services like that that can't handle things intellegently I'll use If/up, if/down network initialization scripts and/or Network-Manager-Dispatcher (which behaves very similar and uses a similar structure to ifup/ifdown scripts)
Needless to say that all of this would be a advanced system-specific configuration and is a nitch need. For a general purpose thing like Systemd it may not be appropriate for it to address this needs.
But if it could then that would be terrific, of course.
The road forward for systemd Posted May 27, 2010 19:34 UTC (Thu) by hppnq (guest, #14462) [Link] There has been a solution [1] for this for a while: ip_nonlocal_bind enables binding to a specific address that is (temporarily) unavailable. Of course, it has nothing to do with systemd, but neither has this problem. ;-)[1] YMMV.
The road forward for systemd Posted May 31, 2010 16:52 UTC (Mon) by mezcalero (guest, #45103) [Link]
There's already a (limited) automatic dependency system in systemd for handling sockets and network devices. For example, if you bind a socket to a particular interface (such as eth0) we add an automatic dependency from the .socket unit to the .device unit of the network interface.
The road forward for systemd Posted May 26, 2010 21:03 UTC (Wed) by spaetz (subscriber, #32870) [Link]
> please read the original blog post. it explains all that. first read, then comment!
Would you please stop telling everyone who has a comment or question that? It is annoying and repetitive. And it is also insulting to assume that I did not read the original LWN article AND the lengthy blog post. I -for example- did and have still questions and doubts. Stop assuming we are all slashdot readers please. Thanks.
The road forward for systemd Posted May 27, 2010 9:38 UTC (Thu) by dgm (subscriber, #49227) [Link]
I have to say that most, if not all, the times Lennart gave that answer the question was indeed answered explicitly in the blog post.
So In my opinion it was not insulting. It *is* a long read, so maybe you just need to read it a couple of times to grasp it completely (I had to).
The road forward for systemd Posted May 26, 2010 19:12 UTC (Wed) by drag (subscriber, #31333) [Link]
> What are we going to do with network sockets and other services, for example? I have an application which bombs out if BIND is not yet started (it needs a resolver to resolve host names when it reads its config). How do I mark this dependency?
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:
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:
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:
You configure /etc/resolv.conf to have localhost as a nameserver.
The road forward for systemd Posted May 26, 2010 22:37 UTC (Wed) by mezcalero (guest, #45103) [Link]
yes this is what happens. basically everything will just work for you, from an app's perspective it makes no difference whether a service it wants to use is running, is being started or is not running yet. the app will see no difference, except maybe in the time a request is responded to.
The road forward for systemd Posted May 26, 2010 22:56 UTC (Wed) by cesarb (subscriber, #6266) [Link]
It is more interesting to consider what would happen if the resolver were in a separate computer, and both computers were booted at the same time.
With systemd, the listening socket would become available very quickly in the computer with the resolver (limited mostly by the BIOS delay); that is, even between separate machines, it could help.
It would be even cooler if it were possible to have service dependencies across machines (so for instance machine A would delay loading a service until a listening socket in machine B becomes available). This would end the problem of having to figure out which machine you have to boot first when the power went out on your >300-day uptime servers.
The road forward for systemd Posted May 26, 2010 23:54 UTC (Wed) by foom (subscriber, #14868) [Link]
Well....DNS maybe isn't a very good example here. Having a DNS socket *exist* isn't particularly useful. If it takes more than 5 seconds to respond, it might as well not bother responding at all, because the client will have given up. And, the resolver library on the client will retry at least once, so even without systemd opening the socket ahead of time, if the system manages to startup Bind in < 5sec, the retry will succeed and everyone will be happy.
The road forward for systemd Posted May 27, 2010 19:50 UTC (Thu) by mgedmin (subscriber, #34497) [Link]
Clients usually wait 30 seconds for DNS timeouts.
The road forward for systemd Posted May 27, 2010 10:32 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
So, systemd should listen on UDP 53 (I don't have Avahi, BTW)? Can you point out where the blog post says something about _network_ services? Can it even be done correctly?
Also, what if I want to listen only on a few interfaces (LAN interface and localhost) - are we going to completely replicate inetd (which I have gladly exterminated from my systems) there?
The road forward for systemd Posted May 27, 2010 15:27 UTC (Thu) by drag (subscriber, #31333) [Link]
> So, systemd should listen on UDP 53
Thats the idea, I suppose.
> (I don't have Avahi, BTW)?
You should. It kicks ass. I've long stopped given a shit about static IP configurations and mucking around with DNS on my network because of it. Services like DAAP are cool.
> Can you point out where the blog post says something about _network_ services? Can it even be done correctly?
OK:
So AF_INET == Network Socket for IPv4
> Also, what if I want to listen only on a few interfaces (LAN interface and localhost) -
No clue. Apparently for things to work optimally the services need to be patched so that they can take care of those sort of details themselves.
Probably with 'dumb' non-systemd optimized services you'll have to edit Systemd configs a little bit.
> are we going to completely replicate inetd (which I have gladly exterminated from my systems) there?
Sounds like it. Hope so. I like things to be simple.
The road forward for systemd Posted May 31, 2010 16:56 UTC (Mon) by mezcalero (guest, #45103) [Link]
Yes, systemd is configured to listen on UDP 53 and then hand off the socket to the real bind.
And, as mentioned we create automatic dependencies between sockets and network interface devices if you for example configure a socket to bind to one particular interface only. That for example is another thing inetd cannot do for you, because it handles only sockets and nothing else. We track and control the entire system state, and hence can easily cover this, too.
The road forward for systemd Posted May 27, 2010 5:15 UTC (Thu) by mordae (subscriber, #54701) [Link]
From the original article: "Note that we make use of the dependency information from the LSB init script headers, and translate those into native systemd dependencies."
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.
The road forward for systemd Posted May 26, 2010 20:18 UTC (Wed) by bangert (subscriber, #28342) [Link]
i have only ever witnessed this level of opposition to a novel idea when roaming the realms of djbware - which incidentially shares many of the core concepts proposed here.
why is it that these systems seem to excite so violent reactions of uninformed disapproval?
The road forward for systemd Posted May 27, 2010 0:07 UTC (Thu) by mfedyk (guest, #55303) [Link]
My understanding is that it is the license for qmail and such that impeed (though by no means stop) its community.
The road forward for systemd Posted May 27, 2010 1:35 UTC (Thu) by rsidd (subscriber, #2582) [Link]
qmail and most of djb's software have been public domain for a while now.
The road forward for systemd Posted May 27, 2010 4:09 UTC (Thu) by njs (guest, #40338) [Link]
Sure, but that happened *well* after the flamewars.
The road forward for systemd Posted May 27, 2010 11:11 UTC (Thu) by cesarb (subscriber, #6266) [Link]
IIRC, there was also the fact that it installed in completely nonstandard directories, and the author was completely opposite to changing to a more normal directory scheme.
And the fact that qmail was a huge source of email backscatter (sending bounces to faked email addresses).
And the lack of AXFR/IXFR in djbdns (rsync, anyone?).
These are the complaints I heard the most about DJB's software. My own annoyance with it (besides the bounce spam) was the "million of tiny _invisible_ files (that is, all dotfiles) scattered all over the filesystem" model for configuration, which made administering an inherited mail server harder than it should be (of course, changing to postfix solved that for me); but I do not recall hearing many complaints about this particular point.
There are great ideas which came from DJB's software (Maildir, which solves the >From problem, is my favorite example), but other software quickly adopted them, negating any advantage for DJB's software. What was left was only the annoyances.
The road forward for systemd Posted May 27, 2010 19:34 UTC (Thu) by njs (guest, #40338) [Link]
Yeah, but if you squint those are all license problems -- because the license (or lack thereof) made them difficult to fix.
The road forward for systemd Posted May 28, 2010 11:03 UTC (Fri) by cesarb (subscriber, #6266) [Link] I do not know if that is the cause, but one possibility is that it is some sort of Hype Backlash (warning: link points to a highly addictive wiki).
Too novel Posted May 29, 2010 20:34 UTC (Sat) by man_ls (subscriber, #15091) [Link] Novel concepts do that: they screw your mind and make you resist the new idea, but in the end they often become the established truth (not with djb though).Aw crap, I'm addicted...
Too novel Posted Jun 5, 2010 11:27 UTC (Sat) by Wol (guest, #4433) [Link]
The trouble with djb (and I speak from personal experience) was that he was a d***head.
I know I made a conscious decision that I was not going to touch any of his software, not because it was bad or good, but because I didn't want anything to do with him the man.
Cheers,
The road forward for systemd Posted May 26, 2010 20:37 UTC (Wed) by stijn (subscriber, #570) [Link]
As a very very minor comment, I would suggest to use on next occassions 'inspired by' or 'taken from' rather than 'stolen from'.
The road forward for systemd Posted May 26, 2010 23:45 UTC (Wed) by neilbrown (subscriber, #359) [Link]
I really like the idea of using automount for all mount points (yes - there is more to systemd than inetd!!). I suspect this could make it a lot easier to arrange systems with /usr mounted via NFS and still have some NFS tools install in /usr (tools that the /usr mount isn't allowed to require, like statd).
But thinking a little further, how does auto-mount wait for the underlying device to become available. Assuming that we configure all local mounts to identify the device by uuid, we would probably need to integrate with udev...
I guess automount just keeps retrying and blocking (rather than failing) if the uuid isn't visible yet - would that be safe?
SJR discusses Upstart Posted May 26, 2010 23:48 UTC (Wed) by MrWim (subscriber, #47432) [Link] There is a video from the Ubuntu Developers Summit where Scott James Remnant discusses systemd. He touches on cgroups and other bits of systemd he would like to see in upstart or he feels doesn't work in the real world. The session is called Upstart Q&A and the bit on systemd starts at 36:15
The road forward for systemd Posted May 27, 2010 1:03 UTC (Thu) by russell (subscriber, #10458) [Link]
Sounds troubling to me>
1. A recipe for unpredictable latency and memory usage. Which can be triggered by outside sources.
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?
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.
The road forward for systemd Posted May 27, 2010 5:24 UTC (Thu) by mordae (subscriber, #54701) [Link]
> 1. A recipe for unpredictable latency and memory usage. Which can be triggered by outside sources.
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.
The road forward for systemd Posted May 27, 2010 6:03 UTC (Thu) by drag (subscriber, #31333) [Link]
With PA I have no problems hotplugging USB audio devices and Bluetooth headphones and then choosing default audio device after that fact. Migrating audio output on the fly to and from multiple devices worked fine, also.
Never used HDMI, though.
The road forward for systemd Posted May 27, 2010 7:04 UTC (Thu) by dmk (subscriber, #50141) [Link]
>> 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?)
Yes. Socket paths are movable. If you want to chroot something, you may need to change the socket path. And sometimes the packager gets it wrong for your setup.
So, in the new system you only need to adapt the socket description of systemd, and the daemon has to implement the hand over.
Cheers,
The road forward for systemd Posted May 28, 2010 17:39 UTC (Fri) by tialaramex (subscriber, #21167) [Link]
The specific issue with HDMI compared to, say, a USB headset is that HDMI isn't just or even primarily an audio connector. Thus whereas a user who plugs in a USB headset can reasonably be expected to want the audio sink to switch to the headset (otherwise, why plug it in?) the user who plugs their TV into the HDMI connector might intend just to use it as a larger desktop, not play their music through it - indeed it may be that their TV can't play music, it's just a display.
So Pulseaudio should probably have (if it doesn't already) a pref that lets you disable its hotplug audio sink behaviour.
(In the ideal world PA would be able to reliably determine that your TV can't play audio, and then ignore the hotplug events from HDMI for that TV, but we don't yet live in such an ideal world)
The road forward for systemd Posted May 31, 2010 17:03 UTC (Mon) by mezcalero (guest, #45103) [Link]
1. This is bogus. We just bootup starter, and start very few things less.
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!
The road forward for systemd Posted Jun 5, 2010 13:35 UTC (Sat) by segedunum (guest, #60948) [Link]
> Please stop the FUDding!
Heh. Did you think Linux was any kind of gaming platform before? It certainly isn't with the multi-second latencies we get with it, and any audio work is completely out of the window now. Don't give me any of that crap about that not being the right use cases either. The Mac manages it. Windows manages it. They're called desktops for a reason.
It's certainly been a nice way to finish desktop Linux off completely.
The road forward for systemd Posted Jun 8, 2010 7:12 UTC (Tue) by michich (subscriber, #17902) [Link]
I'm not seeing any perceptible latencies with PA.. Can you point me to a detailed bugreport?
The road forward for systemd Posted May 27, 2010 7:44 UTC (Thu) by cyperpunks (subscriber, #39406) [Link]
How will sysstemd work with e.g. ypbind?
Should a getent call trigger ypbind to start?
The road forward for systemd Posted May 27, 2010 8:49 UTC (Thu) by neilbrown (subscriber, #359) [Link]
I don't know if the current code does, but it certainly good.
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.
The road forward for systemd Posted May 31, 2010 17:06 UTC (Mon) by mezcalero (guest, #45103) [Link]
I have already patched rpcbind to be socket-activated. It is then started as soon as some client wants to query or register a service; or alternatively at startup but parallelized.
The road forward for systemd Posted May 31, 2010 17:05 UTC (Mon) by mezcalero (guest, #45103) [Link]
Yes, it should. But most likely you should also run it right-away on bootup. Since name lookups will be necessary anyway it would be only smart to start it right-away and not delay it until it is actually used.
The road forward for systemd Posted May 27, 2010 8:54 UTC (Thu) by nim-nim (subscriber, #34454) [Link]
It'd be interesting if the merging of the desktop and system-wide init logic permits things like instanciating one j2ee server per user. This is something that couldn't really be handled by the current system (server init scripts are system-wide oriented, desktop logic does not know what to do with servery stuff) but that java eclipse users really want (one server to meddle with per developper, all listening on different ports)
The road forward for systemd Posted May 27, 2010 10:00 UTC (Thu) by tzafrir (subscriber, #11501) [Link]
Have you looked into D-Bus?
The road forward for systemd Posted May 28, 2010 11:38 UTC (Fri) by nim-nim (subscriber, #34454) [Link]
If your answer is 'you just have to write a new daemon that uses d-bus' that's completely besides the point.
The point is to have an init system able to instanciate existing j2ee servers (certifications, warts and all), either as a system-wide service (production j2ee server) or as per-user instances in the user session (j2ee server instance attached to user ide).
If rewriting with other tech was the answer we'd have java/.net/ruby/whatever OSes by now.
The value of a good init system is too be able to manage existing software gracefully.
The road forward for systemd Posted May 28, 2010 13:56 UTC (Fri) by tzafrir (subscriber, #11501) [Link]
You want those for development time? This should, then, be related to the IDE. Registering them to them system makes it a whole more difficult to debug a single component.
The road forward for systemd Posted May 29, 2010 8:15 UTC (Sat) by nim-nim (subscriber, #34454) [Link]
Nooo
You don't understand
People doing dev want their private daemon that is identical (ports excluded) to the one they will have system-wide in production
As soon as you start changing it so it does not behave like the system one you reduce the whole setup value.
The road forward for systemd Posted May 27, 2010 13:41 UTC (Thu) by keybuk (subscriber, #18473) [Link] Upstart doesn't quite use the "traditional" post, as you say. I've tried to explain the difference in a blog post, which might also help explain the technical disagreement between myself and Lennart (at least, my side of it). Dependency-based & event-based init daemons and launchd
The road forward for systemd Posted May 31, 2010 17:40 UTC (Mon) by mezcalero (guest, #45103) [Link]
Hmm, my comments there don't seem to show up on the comments section on your blog. So here's my reply to your blog story:
First of all, you create the impression that systemds 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, thats 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 launchds or systemds 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 theres a file in the CUPS spool dir. Its 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 dont see how the current Upstart could do anything like this
So, on this topic: systemd 1, upstart 0.
And finally, I dont think you have really understood launchd or systemd. The focus is on using socket-activation for parallelizing and getting rid of explicit dependencies. Its much less on on-demand loading.
The road forward for systemd Posted May 28, 2010 16:35 UTC (Fri) by viro (subscriber, #7872) [Link]
> Next time something is added to the kernel please mark it as "Hey, please
> don't use it, this is only here so that you don't use it. Thanks!" Maybe then > dumb-ass folks like me will notice and refrain from using it.
Perhaps the self-described dumb-ass folks wouldn't mind taking a look at the source and deciding if the implementation (and interface design) are too revolting to touch?
Moreover, if there is any piece of software that absolutely Must Not rely on optional kernel features, /sbin/init is it. It has to be able to run on any kernel, and survive things like kernel developer doing bisects jumping back and forth across the point where the damn thing had been added.
Damnit, people, has the mess with udev compatibility taught you nothing? If anything, init is worse than that; it is (thankfully) possible to run system without udev, not to mention dbus, hald and the rest of those turds. Doing that without working init is not possible. Sigh...
cgroups for dummies Posted May 30, 2010 10:48 UTC (Sun) by man_ls (subscriber, #15091) [Link] In two or three years this point will be moot: all kernels without this feature will be considered ancient history (like, say, 2.6.25 now). If you are designing a next-generation init system you should certainly be able to rely on anything already included in future kernels.
The road forward for systemd Posted May 31, 2010 17:12 UTC (Mon) by mezcalero (guest, #45103) [Link]
Well, first of all, it's Peter Zijlstra who called us "dumb-ass", I didn't come up with that.
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?
The road forward for systemd Posted Jun 4, 2010 14:18 UTC (Fri) by obi (guest, #5784) [Link]
Irrespective of whether SystemD or Upstart is the greatest thing since sliced bread - honestly, both would be an improvement, and I can't yet wrap my head around which one would be better - the mess with udev is hard to miss.
Just recently I got a message while upgrading saying udev >150 is incompatible with a kernel I was running, that had CONFIG_SYSFS_DEPRECATED compiled in. Now, it's not a huge deal, but udev and init are "special"; developers can collectively decide that using certain new features and conflicting with deprecated features is the right way forward, but I'd prefer people to thread carefully and would like this to happen rarely. With udev this happened a bit too often, and it has burned users in the past. The whole "upgrade udev in lock-step with your kernel" is a little... annoying.
That being said I do understand it's worth it sometimes.
The road forward for systemd Posted Jun 1, 2010 9:06 UTC (Tue) by __alex (subscriber, #38036) [Link]
If the merit in systemd is indeed technical and it is already possible to boot systems with it, where are the benchmarks showing it beating upstart?
The road forward for systemd Posted Jun 1, 2010 16:11 UTC (Tue) by SEMW (guest, #52697) [Link] If you find the explanation in the article inadequate ("Sorry, no bootcharts or hard data on start-up times for the moment. We'll publish that as soon as we have fully parallelized all services from the default Fedora install. Then, we'll welcome you to benchmark the systemd approach, and provide our own benchmark data as well"), you might get farther by posting your actual problem with it. Just rhetorically asking "Where are the benchmarks?" might mislead people into wrongly thinking that you just hadn't read the article.
The road forward for systemd Posted Jun 1, 2010 16:18 UTC (Tue) by __alex (subscriber, #38036) [Link]
I don't have a problem with it. It just seems that discussing it's technical merits is a bit philosophical when there's no published data on exactly the sort of thing people will be expecting it to improve.
The road forward for systemd Posted Jun 1, 2010 17:55 UTC (Tue) by anselm (subscriber, #2796) [Link] I don't worry about the boot times a great deal – even with the traditional init my machine boots a lot quicker these days than it used to. So never mind the benchmarks; if systemd merely does the other things it is said to do, at upstart's or even Sys-V init's speed, that will be just fine by me, and I'd be happy to just skip over upstart, thank you very much.
The road forward for systemd Posted Jun 3, 2010 21:37 UTC (Thu) by oak (subscriber, #2786) [Link]
I think the largest Upstart issue is that its dependencies don't solve the issue that just starting the service is not enough for the clients. The server's socket needs to be available too, otherwise the clients can abort.
With Upstart one needs to modify the servers and have some extra code to communicate with these mods from the Upstart or its scripts. Or to have some trivial utility waiting & polling the server's socket availability before Upstart can fire the "started" event. If you don't have these with Upstart, your bootup process is fragile to timings issues.
That's the problem that systemd seems to be nicely solving. Doing the dependencies _correctly_ (based on server's service, not execution) with minimal modifications & complications required.
Better kernel support Posted Jul 7, 2010 21:28 UTC (Wed) by nas (subscriber, #17) [Link] It seems to me that a better solution would be for the kernel to provide explicit support for this model. To be sure, it would require some serious work to get the interface correct. I'm thinking of something similar to udev. Perhaps a user space program could register its interest in a certain events (e.g. connection to a certain port) and take appropriate actions (e.g. start a daemon).
Better kernel support Posted Jul 13, 2010 8:40 UTC (Tue) by smurf (subscriber, #17840) [Link] Perhaps a user space program could register its interest in a certain events (e.g. connection to a certain port) and take appropriate actions (e.g. start a daemon).That's exactly what systemd does right now. The kernel doesn't provide a mechanism to queue TCP SYN packets until the corresponding port gets opened. I don't think there should be. Either some process is listening on a port (you send a SYN+ACK back), or not (you send a REJ back).
Better kernel support Posted Jul 13, 2010 9:01 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
hmm, diald was caching network packets while it opened a network connection a decade ago. why can't the same mechanism be used for the inbound packets?
no, I don't remember the mechanism, but in the dial-up days I used diald extensively
Better kernel support Posted Jul 13, 2010 9:09 UTC (Tue) by paulj (subscriber, #341) [Link]
Yes it did. IIRC it used an ethertap device to forward the packets up to itself in user-space. Then when the line was up it would repoint the default route to the ppp (or whichever) device and send out the packets. Very neat.
The road forward for systemd Posted Jul 27, 2010 21:20 UTC (Tue) by sebikal (guest, #69267) [Link]
Hello systemd folks :)
I've been trying out systemd for a few days and seem to have a bit of an issue. The way I've installed it is using a Fedora core 13 installation, then "yum install fedora-release-rawhide" then installed fc-14 systemd with yum. I'm booting the system using kernel boot args "init=/bin/systemd systemd.default=multi-user.target". The first time I did this I was unable to log in the system (not even through virtual consoles). To get past this, I issued "chcon -t init_exec_t /bin/systemd" and that fixed the login issue. However, sshd starting per connection basis is not working. Systemd is not starting sshd when I try to connect through ssh. Initially, I did not have any of the sshd.service, sshd@.service nor sshd.socket files. Shouldn't they have been installed by the systemd-units rpm package? Then, I copied them over from http://0pointer.de/public/systemd-units/ but to no avail. I first need to manually start sshd in order to connect with ssh. Any ideas?
The road forward for systemd Posted Jul 27, 2010 21:33 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]
This sounds like a bug report you should file in http://bugzilla.redhat.com against systemd. Please do that.
The road forward for systemd Posted Jul 28, 2010 7:12 UTC (Wed) by sebikal (guest, #69267) [Link]
Thanks for the suggestion. Has anybody had any success with on demand starting of sshd?
The road forward for systemd Posted Oct 21, 2010 8:17 UTC (Thu) by sebikal (guest, #69267) [Link]
ssh per connection still not working
When trying to connect to the ssh server, systemd spits out a "function not implemented" message. Any thought on this?
thank you
|
|||||||||||||