Shared publicly  - 
 
So it appears that the Debian ctte discussions are now stuck at a 4:4 stalemate between systemd and Upstart.

What I find interesting about this, is that during the discussions some of the most fundamental questions were never asked: do the three contenders actually do what one would expect from a modern system that brings up the system and manages services? Are they substantially better than what sysvinit provided?

When looking at the boot process of modern computers, there are some bits that are certainly more important than others. One of the most important ones is getting the logic right how file systems are set up: the system needs to wait until all block devices from /etc/fstab have shown up, have been fsck'ed and have been mounted. Only after this has been done for all file systems listed boot may proceed.

On sysvinit this crucial part of the boot process was very poorly implemented: there was simply no scheme in place to wait for the devices from /etc/fstab to show up. Instead, through a mix of sleeping + "udev settle" + scsi_wait_scan the system would wait for a point in in time where "all" devices have shown up, then it would fsck them all, and then it would mount them all. This scheme worked fine on 90's hardware, since all hard disks were local and storage systems simple: it would be unlikely that devices would not have been found and probed within that magic sleeping interval. However, this is really not how modern computers work. Nowadays pretty much all hardware is hotplug capable, and for most hardware there is no time guarantee whithin which all connected devices have to have shown up (and this can get quite bad, for example on USB or iSCSI, or RAID stuff). Thus, any scheme that doesn't take into account which the devices are that need to be waited for, is simply unreliable and slow (since one doesn't know how long to wait, one has to wait for longer than really necessary). Reliability is crucial for server setups, and boot times for client machines. sysvinit is good at neither.

Now, when we look at the three contenders, we notice that one of them brings exactly nothing to the table here that is any better than sysvinit here: OpenRC does not understand /etc/fstab, it has no facility to wait for the devices listed in them, fsck them, mount them.

Upstart is much better here: it contains a binary called "mountall" that will wait for the devices in /etc/fstab to show up, will fsck them and mount them. So on the first peek everything is fine, it should be sufficient to just call this at boot and all is good, right? Well, in a way that's true, however I think the existance of this tool exemplifies, illustrates like little else how insufficient and broken the basic Upstart design actually is: even though Upstart is "event-based" and all, the most crucial, relevant part of the boot process it cannot cover: the waiting/fscking/mounting takes place completely outside of Upstart's rules engine.  The Upstart developers resorted to a completely external state machine for the most important part because they coudln't map it to Upstart's design. But what good is the design if it cannot even cover this central part of the boot process?

(I figure I don't have to mention this: systemd OTOH will parse /etc/fstab, and integrates its contents neatly into the dependency tree as little more than just another source of configuration.)

The existance of mountall on Upstart, and the non-integration of /etc/fstab into the Upstart rule set, results in a lot of additional shortcomings: mountall is a one-time thing for the boot process, all context of file systems, devices and mounts is lost, after it ran, and the file system state is henceforth assumed static. Which of course is not how systems work these days...

This design flaw is one of the things we noticed when we looked into Upstart in detail before we decided to start systemd. 4 years later, nothing has changed, the Upstart design still cannot cover this...

And there are more low-level questions like this one should ask, that should appear as absolute baseline what to expect from an init system. For example:

a) Does the init system support auto-respawning of services on failure/coredump/..?

b) Does the init system record exit status/signals/coredumps of services for later retrieval by the admin?

c) Does the init system record stdout/stderr of all system services for later retrieval by the admin?

d) Does the init system support timing out all service operations such as start or stop?

e) Does the init system support rate-limiting all service operations such as start/.. ?

f) Does the init system support basic resource management operations for services, for example, limiting CPU usage, memory usag, IO usage of a service, and so on?

And so on... Of course, systemd will cover all of the above fine, since we wrote it specifically with an enterprise usecase in mind, which needs to cover all of this. Note that the the points raised above are hardly something of the fancier features of systemd, they are really just the absolute baseline a service manager should cover. OpenRC falls short on most of these, Upstart faires considerably better, but it certainly doesn't cover it all...
188
29
Jeffrey Gelens's profile photoWolfgang Walter's profile photoKeshav Kini's profile photoMike Crowe's profile photo
77 comments
Koen Kooi
+
1
7
8
7
 
Bdale's vote counts double, so it's technically not a stalemate. Then again, we're talking about debian politics.
 
Hm, and I thought I recently read there'd be an unexpected preference for systemd. I guess I have to check where I actually read this.
 
You glossed over how Debian is forcing LVM to "work" by forcing a udev-settle to be run. Why? To allow other init systems to "work". So even if they would go for systemd, I think they'll still make questionable fixes that really don't fix things.

Yay for simplified "but LVM should work across init systems" and "OpenRC is good enough!!!" posts (see latest posts on debian-ctte mailing list). :-P
 
+Koen Kooi interesting. Then I hope that none of the ones in favour of systemd (or rumoured to be in favour) changes side. 

I hope that the choice goes in favour of systemd. (My debian laptop is currently running pretty fine with systemd).
 
"Only after this has been done for all file systems listed boot may proceed."

Interesting that you put this in here, as I find most useful the fact that you don't need to wait for all filesystems. I give all my filesystems the noauto and x-systemd.automount options and just let them get mounted as and when they're needed. That is simply not possible in mountall's current design.
 
What about the CLA? Can't believe Debian is even considering it with the CLA in place.
 
+Lilian Moraru maybe they don't expect to push improvements upstream? I also don't follow that. The technical side is one thing but when I was reminded about the cla I kept thinking it would basically disqualify upstart because it was in conflict with core debian philosophy.
 
One person in that committee mentioned that only current features should be considered. But that's largely ignored in latest discussions. E.g. the forking bit mentions that they'd assume they'll just become upstream. Same with logind, they'll "just provide an alternative". Others mention that things like logind aren't a concern at this time, only for later. Really interesting way of deciding.

I missed some of the last discussion. OpenRC is ok because you have Monit. Urgh.
 
From a Fedora point-of-view, I'm almost wanting Debian to choose Upstart, and slowly disappear into insignificance.
 
Diversity is good. They know they have some catching up to do. You've told them exactly how deficient their solution is. Let them try their own thing. Besides, conformism is boring and what Debian does shouldn't really affect systemd or its users.
 
+Richard Hughes Debian has it's place and it's role in the GNU/Linux ecosystem just as Fedora has.
 
The fact is this constant competition between open distributions and community's for users in the GNU/Linux ecosystem is a bit silly.

Regarding Debian the fact is Canonical has forked itself to an island and is dragging Debian along with it to that island with the added maintianership burden downstream of their forks so they will have to maintain cgroups, gnome-session as of 3.14, Hans root less xorg work kdbus basically any future changes in the plumbing layer + x +wayland + Gnome I would think.

If the choice will not be systemd and I was the downstream systemd maintainer in Debian I would say thanks but no thanks and walk away because this argument has being going on for over a year now with more or less every systemd upstream maintainer justifying every single line of code with hand reached out to the Debian community in helping in making the transaction as smooth as possible but that hand will not be reached out forever. 

This is the year that justification of systemd comes to an end and people start focusing on moving forward with the bits...
 
+Andrew Cooks: Why is diversity good? It eats up loads of development time. One more layer of abstraction is not a good thing. There is a XKCD comic about it. Further, this decision is important. If you want to work on plumbing layer, but Debian goes for the 'someone should do some unspecified amount of work' or 'whatever you decide should just be compatible across init systems'. This while ignoring or glossing over the technical arguments you're making then I don't believe you can say this decision is not important.
 
+Dominik Hannen Nor do I, but the alternative -- a complete lack of diversity -- is arguably worse.

At the end of the day, if the Debian developers want to spend their time working around the fact that the rest of the Linux world is moving on without them, that's their problem. It's not the kind of Linux I would want to work with. But if other people were to think doing that work was a worthwhile use of their time, I wouldn't be able to say that their decision was "wrong".
 
+Michael Chapman: Could you explain why to this specific point? I know why having one init system is good. However, at the moment nobody is saying why multiple is a good thing vs the obvious cost. It seems like the cost is ignored.

I'd appreciate a practical and concrete answer (related to init systems), not a theoretical one.
 
+Olav Vitters there's nothing really specific about init systems. Diversity is good because it's the only way to ensure open progress without single mindset. Let's say we agree that sysv init had it coming and upstart appeared, if you had your way systemd would have not have existed at all because upstart was there. Now you say systemd is great and already there's no other better way to do things... but you're killing other branches (the loosely coupled ones) of evolution, imagine if life on earth had only one branch, wouldn't it be fantastic.

So you see I don't know if this is a theoretical answer for you but it sounds pretty concrete to me ☺
 
Having said that I'm currently using Fedora and systemd rocks ☺
 
+Olav Vitters I don't have one, but I can try to guess.

Debian's motto is that it's the "universal operating system", and as such no decision should be made that gets in the way of others choosing to use alternative, perhaps "non-standard", components. That's why it supports multiple kernels, for instance. Supporting multiple init systems is just an extension of that.

I agree with you, I do think this kind of thing is a big cost. So big, in fact, that I prefer not to use Debian -- I personally think such things get in the way of making a Linux distribution truly usable. But if other people think the cost is worth it, and if other people actively enjoy going to all that effort, who am I to say they're wrong?
 
+Michael Chapman I cannot follow that argumentation, because I do not believe that it is applicable to free open-source software.

Diversity, if needed, is always available with forking. Also there are a lot of other init-systems which will not go away because of the irrational hate some people feel..

On the flip-side, it is a daunting task to port for example Unity to a non-Ubuntu distro, because of their custom patches to a lot of packages.. This kind of diversity makes it hard for any non-Ubuntu distro to pull any value out of the work Canonical puts into software.. Not sure if that is intentional though.
 
+Nuno Ferreira: Thanks, but they were planning to change Upstart initially, changing the design and/or forking it. You can have one thing at a point, then fork it and go in another direction. Another example is GNOME vs MATE/Cinnamon. Continuously going for "choice" is IMO just wasteful / stop energy and IMO a bad decision. I don't think stuff can never be changed, even if there really is just one option at a certain point.
 
OK. I guess what I'm saying is that I don't see Debian not choosing "we support only systemd on Linux" as being actively harmful to the systemd project itself, or to other distros. Disappointing, maybe, but that's all.

Furthermore, if people want to do things differently, I don't think actively trying to stop them doing that is a terribly good idea. Linux may not be about choice, but people should still be free to make their own choices (even bad ones).

For my part, I'll stick with a distro that makes generally good choices for me.
 
So Bdale will cast the deciding vote, which means systemd. This is good. IMHO.

… except that I'm sure some people won't like that idea, and call for a General Resolution. Which means, at best, another month or two until Debian gets an uptodate systemd. Sigh.
 
Funny you should mention mounting filesystems because I recently had to spend more time than I cared for trying to figure out why I had to wait for a systemd timeout on mounting my filesystems... (on Fedora 19)
It wasn't immediately obvious (too much on screen to make sense of it all - that is, once you've managed to escape plymouthd..), shouldn't have been as disruptive as it was (some mountpoint in /opt, system was perfectly usable without it - no need to drop me to a root shell for that), and I couldn't see a way of skipping this painful timeout (more painful if you have to go through the process a number of times).
It may well be that for a number of those issues the PEBKAC. After all, I caused it by shuffling some disks around. But I have found it harder to solve than I did in all those years of sysvinit/openrc.
My point is that for many enterprise systems that I care about, predictable/slower is still a win over fast/socket-activated, if the latter is potentially more problematic to diagnose.
It may be that for many use cases, systemd is the best design and implementation to do things right, but claiming that it is universally better in all aspects is a non starter. And I think some of the push back comes from people like me who have little or nothing to gain from the switch to systemd.
Disclaimer: I prefer openrc, the other two complicate things for benefits I do not care about. Also, I am not here to start a flamewar - just trying to get a point across - and maybe help you guys understand the other side's point of view, which I have seen too often dismissed as irrelevant or misinformed - which it is not.
Tim JP
+
1
0
1
0
 
What really surpises me is that none of the members ever acknowledged the fact that no one uses their silly HURD and kFreeBSD variants. They are at 0.09% marketshare according to popcon.debian.org. Combined! You are more likely to give birth to a two headed albino baby than finding a Debian/HURD user. How can anyone really consider rather taking the second best option just to fill the 0.09% gap? Only 9 out of 10.000 people don't use Debian/Linux and half of them are probably just toying around in a Virtual Box.
 
+Antoine Martin That sounds like "nofail" in the mount options, which isn't different in systemd than for sysvinit...

And non-parallel boot is a myth, sysvinit does this only on the surface, everything started by dbus-daemon for example is parallelized anyway even then and there's not really a way around it.
 
+Andrew Cooks, +Olav Vitters I'd personally actually welcome good competition, i.e. some other project we can compare ourselves too and get impulses from. For example, reading through the SMF docs was highly interesting and inspiring for us. However, Upstart fails hard on that, there's nothing to learn from that, there's no inspiration to get from that, in the last four year almost no progress happened.

I am actually suscribed to the Upstart commits mailing list, since I want to know what they are working on, in the hope there might be something good in there for us. I keep myself quite informed about what they do. Sadly, the competition thing doesn't work the other way, they never look the other way, they live on their little island isolated from the rest of the world. Sometimes the try to check boxes, by adding things like "socket activation" to Upstart, but they do it completely misunderstanding the concept, and in a useless way.

So yeah, competition would be great, but quite frankly, Upstart doesn't really work as competition.
 
What's in question here is whether Debian has the freedom to make its own decisions, not just the technical merit of systemd over upstart. Some are acting like politicians, trying to tell people what to do, as if they're somehow trying to take the food off our tables. Are we going to have another civil war / holy crusade over package managers when we're done with this? Surely the lack of one true package format is holding us back? 
 
I think the debate about diversity is misleading. The situation we had was some SysV-Init which evolves in different ways in different distributions. Its limitations finally resulted in the creation of "better" alternatives like systemd, upstart, cinit, openrc and so on. So the past should teach us that the decision for one stable init system for a stable distribution does not kill diversity nor kill it new ideas in different directions.
 
+Kristian Høgsberg I don't think there are any official "result" as the exact wording of even the question the ctte is answering is not finalized yet. However, most (all?) ctte members have posted their opinons to the list and i guess +Lennart Poettering just counted those.
 
+Kristian Høgsberg
There is no official vote yet, but membes of the tech ctte have mailed their vote intention in the thread. I've collected links to specific messages in my blog, in case you're insterested ( http://j.mp/1cMosIf ).
 
I am not sure that every point from a through to f in your last list is essential to a baseline init.  It reads more as if you have decided to make the things you implemented a de facto baseline.
 
openRC runs on Debian, systemd doesn't. That's a huge advantage.
 
+Kristian Høgsberg You have to read each member's position statement. For upstart, it's team Canonical (Ian, Steve & Colin) & Andreas, on the systemd side, it's Russ, Keith, Don & Bdale.
 
+Lennart Poettering JFTR you are missing one point that is also important for Debian - we want to support non-Linux kernel architectures. And that's what makes the decision difficult.

Edit: This might influence the outcome in the way that we will have default init for each kernel.

+Tim JP It's not about the usage numbers. It has been pointed out that supporting different kernels actually does improve the overall quality of the software (just search the mentioned bugreport).
 
+Christoph Anton Mitterer Also spreading your FUD about Steve and Colin here? You are really disgusting. Just go away, we have told you several times that we (as Debian Developers) believe in our CTTE members and you are still spreading this bullshit about them. You are really horrible person pushing your personal views as grand truths everywhere.
Tim JP
+
1
2
1
 
+Bónis Machó What makes you think that systemd doesn't work on Debian at this point?
 
Funnily, the fact systemd waits for all filesystems listed in /etc/fstab led me to some problems last time I went away without my external hard disk. I have a mount point for it and it doesn't have the noauto option because I want to mount it a boot when it's available but I don't want to wait for it. The boot obviously failed when I tried to boot without it. So I looked up the documentation and added "comment=systemd.automount" and now the boot works again.

But the first time that an application tried to access a file below the mount point, it blocked to wait the hard disk I don't have instead of failing. I'm wondering if systemd has a good answer to this or if this is something that can only be done at the udev level...
 
+Ondřej Surý Non-Linux Debian systems can continue to use SysV init, or do something else, or fork systemd. After all, the old init scripts are not going to get magically deleted the day Linux-Debian switches its default to systemd.
That is the problem of the kBSD/Hurd maintainers, just like it is now their problem, and not the job of $random_package.maintainer, to test whether $random_package in works there.
 
+Matthias Urlichs You have misunderstood me - I am merely saying that support for the non-Linux arch affects the decision making of CTTE. My personal opinion is that we should go for systemd/Linux and OpenRC/kBSD+Hurd.
 
+Ondřej Surý are those ports truly backed up by the Debian community due the added load they bring to the service sub-community in Debian ( infra,releng,qa ) as well as on maintainers themselves?
 
+Alberto Mardegan Steve Langasek has previously states he will eject himself from the ctte voting since he is the maintainer of upstart. Will be interesting to see if he actually stays away from voting in the end.
 
The sad thing is Debian's choice, be it due to nonportability or CLA's, is a political one. Because both of the main candidates are seen as a big improvement over the current solution, the tech-ctte is essentially tasked to decide what option fits better with the Debian project.

My feelings is that both external parties are lobbying Debian to their side to an extent. It's understandable. If Debian chooses systemd, with all the monolithic support received from the kernel up to gnome, Canonical would be seriously screwed. Furthermore, if Red Hat got Debian into a similar release schedule, patch maintenance would probably simplify.

On the other, If Debian chooses upstart and somehow manages to break systemd's stronghold in other projects (because Debian is big), that could bring extra maintenance to some packages, plus the single init mindset would disappear.

I'm anyways really sad to see the BSD systems so terribly screwed. First it was KMS, now it Gnome, next is who knows.  We shouldn't forget how important they are for the free software community.

And finally, my tinfoil hat theory to completely destroy all my credibility: Red Hat is using systemd as an Embrace, Extend, Extinguish weapon on the rest of the free software community.
 
+Miguel Martinez: systemd doesn't have a stronghold over GNOME. Speaking as a GNOME release team member (and no, I don't work for Red Hat!). Systemd provides things that we need. One of which is logind (the API). Other init systems do not provide any solution or alternative. This is being totally ignored or glossed over with answers such as "we'll maintain a fork and it'll be alright". Your answer also is essentially "Debian is big enough that it'll be alright".

Suggest reading the blog posts I wrote:
http://blogs.gnome.org/ovitters/2013/09/25/gnome-and-logindsystemd-thoughts/
http://blogs.gnome.org/ovitters/2013/10/10/wayland-vs-usrsharexsessions/

From what I see you're just not aware of the reasoning. It keeps getting simplified to just an init system discussion, while that's not what GNOME requires / depends on.

If Upstart is chosen, it will not have an affect on the logind dependency. Why, because Upstart doesn't provide any alternative (further, we don't want a different API)! What I expect is that'll take a much longer time before software can get into Debian. At the moment Ubuntu is lagging behind in integrating GNOME. So cannot just take things from Ubuntu, they're already behind. In practice, Debian will have the same with Wayland, GNOME, etc.

Now starting about weapons, etc: systemd developers attend loads of conferences and hold lots of hackfests. Loads of contributions from various individuals, companies and organizations.

To me the arguments against systemd make no sense at all. The technical reasons are very limited (Linux-only, though understand that it is very important for Debian). The problems it solves or the problems the others don't solve are really important. It is rather annoying to read the discussion. Glossing over important things and instead focussing on non concrete things such as "diversity", "stronghold" and so on makes it very difficult to plan ahead (my GNOME point of view). Planning ahead is good! I can more or less trust systemd, vague claims, promises, "I'll be alright", etc, nope. I tend to ignore vagueness.

Lastly: you claim a stronghold, while at the same time Debian should use its power to break this stronghold. Seems you're actively trying to do what you think is bad about another project.

PS: I know someone with the same name as you :P
 
+Olav Vitters , very few people are trying to understate the technical achievements of systemd. But choosing it "just" because it's technically superior today needn't be the right answer. Was Linux the technically superior option at everything when you migrated? Is it today?

Additionally, sometimes one feels that features not in upstart today won't be there tomorrow. My experience with scientific software is that, if something is important, it will be added. Or you switch. Does it require work? Yes. Will it be working tomorrow flawlessly? No. But it is not the insumournable wall some make it look, especially on a copyleft world.

Also, when you write "It keeps getting simplified to just an init system discussion, while that's not what GNOME requires / depends on." you show what many people find alienating in systemd. And it's telling how you mention that gnome 3.8 doesn't have a hard dependency on systemd thanks to a last-minute patch.

It's somewhat hypocritical to say that upstart provides much less features than systemd, when systemd is, by design, trying to take over much more than upstart ever did. Mind you, this doesn't excuse upstart for not having stuff like cgroups working.

Is there any technical reason why there couldn't be a, let' say, upstart-logind?

Finally, you're being fallacious with respect to the strongholds. I've never suggested Debian should maneuver so that third parties only provide debs that assume and stick to the Debian way. That would be an equivalent situation.
 
I got tired of reading all the comments. Seems to me there is a lot of this: systemd is better than you. This reminds me of the old holy wars: vim vs emacs, gnome vs kde, rpm vs dpkg. If we can't find anything to fight on, better find something quick.

If systemd is really that good, then it will stand on its own two feet, and will get adopted. If not, the proof is in the pudding.

I do find it interesting that the OP glossed over one big detail: debian supports other kernels outside of Linux. Because systemd is Linux-only, this brings a big unnecessary maintenance burden on the developers.
 
+Aaron Toponce: Lennart wrote about that extensively on that in the past.

"Because systemd is Linux-only, this brings a big unnecessary maintenance burden on the developers."

I don't understand what you mean. Which developers? The Debian packagers porting to non-Linux kernels? What is your alternative solution then?
 
+Miguel Martinez: It seems you didn't read my blogpost. All the questions you're raising are explained. The problems I've highlighted briefly here are also explained. I wrote about it before. GNOME 3.8, nor 3.10, nor 3.12 require logind. Reality: ConsoleKit is unmaintained and logind is used on Ubuntu.

Suggest instead of asking me to repeat things I've explained before to actually read my blog. Asking me to repeat while not taking the time to read makes me not want to spend the time to repeat.
 
+Miguel Martinez Red Hat is entirely irresponsible for what's happening other then to the extent of signing the paycheck for  some of  the individuals involved.

There is a collective and collaborated effort stopping the fragmentation and bringing the plumbing layer to whole between maintainers and distributions because quite frankly after all those years people have grown sick and tired trying to support,integrate,maintain,qa,documenting. etc, each and every fracking variating implementation of the same thing that have been invented and fork since the dawn of *nix in the name of choice and the same time never been able to properly rely upon or take step forward in the GNU/Linux ecosystem and advance it.

If and when a technology superior solution emerges that solves real problems arrives to what already exists and is implemented in that stack, the current implementation will be replaced nobody says otherwise and not doing so would hinder progress.

The fact is the most advanced init system that exist today is systemd and the era of hot swappable base/coreOS is coming to an end, and Debian is more then welcome to participate in that effort with the rest of us and reduce load on themselves in the process or chose the alternative following the cla and fork path of Canonical to their island of choice

http://www.talend.com/sites/default/files/cast_away.jpg
 
+Aaron Toponce
 systemd is getting adopted already in debian... deb's popcon shows its got traction as an alternative init already.    As long as the ctte continues to allow alternative inits to exist and be used... systemd adoption will increase in the Deb-linux  userbase, I have no doubt. 

I think the porting benefit for Upstart isn't as clear as people make it out ot believe. There are some long standing..deep design bugs.. which Scott, as the original maintainer planned to fix by re-writing upstart to make use of linux specific mechanisms like cgroups. 
For example: https://bugs.launchpad.net/upstart/+bug/406397

Please read all the comments in the bug if you can to get a feel for how far this one bug impacts the breath of services in Ubuntu.  But if you can't read them all, read all of Scott's comments. I'll hilite a few:
https://bugs.launchpad.net/upstart/+bug/406397/comments/13
rationale for low priority handling... affected services not deemed a
priority for Upstart porting.
https://bugs.launchpad.net/upstart/+bug/406397/comments/7
Scott suggests relying on cgroups is the fundamental fix
https://bugs.launchpad.net/upstart/+bug/406397/comments/21
Scott mentions a rewrite of the underlying upstart design is needed
and is happening... but such a rewrite has never materialized.

The new maintainers have not addresses this particular bug, from 2009 yet, and I've yet to see a plan put forward other than Scott's original plan to rewrite upstart to make it use more linux specific APIs. When the main developer of a project looks at a bug and decides the only way to fix it is a major deep rewrite of the project... that's a red flag for me. Why on earth would anyone choose to port this before the identified rewrite was complete? I think that's irresponsible of the current maintainer team...to encourage a porting effort while at the same time blithely ignore the previous communicated dev roadmap..without even a comment with regard to how the plan to address the bugs the rewrite was intended to address.

So really I think the porting effort for Upstart is putting the cart before the horse.  It's a political win in the scope of the Debian discussion, but I think it does the Debian porters a huge disservice by encouraging them to use an init system with a deeply flawed implementation.   Regardless of what the ctte decides for the linux default, they will have to evaluate whether upstart really is good enough for their needs.  Personally, you know as a person, I think openrc is a better fit for them than upstart. Openrc might not be a huge benefit from sysinit, but I'm not seeing fundamental flaws in its design which cause it to lose track of service state entirely... unlike upstart...which has multiple bugs, not just this one, which result in upstart losing track of the service its managing.

-jef
 
+Aaron Toponce You really didn't read anything...
1. systemd does get adopted. 1 example is GNOME. And there are many more. If you want to find out why, you'll have to read.
2. The scripts and the init system currently in use doesn't disappear. For Linux they can switch to systemd and for the rest if the maintenance is a problem, they can keep using the same stuff. 
 
+Christoph Anton Mitterer I don't agree with you. I think they vote based on company's interest.
When Mark was raging on the community it was proved that no one will say something against or do something against to be able to keep their jobs (which btw is considered being professional, any company would expect their employee to act in favor of the company).
I understand you would prefer to think otherwise but this is "being professional".
 
About those essencial expected features

a) - Respawning? Yes, I would like to be able to rely on init system to do that.

b) - Record exit code? Makes sense as well - init system uses syslog for that.

c) - Record stdout/stderr. There's a program for that - it's called syslog. Writes nice text files, can send those over the network. Etc, etc.

d, e) Timing and rate limiting are nice to have

f) Resource management. What for? On desktops most services use are something between 0.01% and 0.00001% of available resources, on servers - I don't want fo find out that my apache/ngingx/whatever suddenly can use only one core and 16Mb of RAM just because init system contains default settings.

g) Can it make coffee as well?
 
The ulimit for the init process is capped at 1024 meaning more than 1024 processes cannot be started by init on upstart.  Does systemd have a similar limitation or does it use /proc/#/ logging in a similar way?
 
+Michael Baikov c) systemd takes stdout/stderr and forwards it to the journal (which is like syslog++)
 f) resource management is to prevent one service (running on a server) from overtaking all of the other services running on the same server. On the desktop, it can be used to prevent a DoS or a buggy service from making the whole machine crawl. etc, etc
 
+Paul Wagner unlike Upstart systemd is not a monolithic beast. In systemd the logging is handled outside of PID1 in the journald process. And that process runs with NOFILE bumped to 16k by default.
 
+Olivier Crête
 I'd say more like syslog--.. I was asked to help to fix a problem with some website on system which used systemd  some time ago. On every service restart (both - successful and unsuccessful) it  was producing something like "output copied to the journal" with no other indication. On IRC channel they said that this is expected behaviour, it was designed that way and it's much better than old behaviour when every daemon could spew all kinds of into to stdout/stderr.

As for resource management - if one service is overtaking over whole server it's either misconfigured or external conditions had changed. I don't see how any init system can fix that.
 
+Michael Baikov: "If a service is misconfigured": With systemd you get easy access to all the resource management the Linux kernel has. Instead of manually hacking init scripts or adding code to every daemon (bugs galore), you can configure it the same place across services/daemons. That you don't understand the benefit seems very odd. Further "external conditions have changed": so not your problem you're saying? With properly setting resources even with "external changes" you can limit it.

The behaviour you describe is very odd. Journal makes things much easier, especially e.g. working with openldap. Which distribution is this on? Wonder if it was properly setup or not or that this is a contrived example.

It seems your objection to systemd is: "I don't see the need for what it does?"?
 
+Jóhann B. Guðmundsson
You can probably imagine there's no single opinion in the Debian, and there are developers who think we should drop non-Linux ports and there are developers (including me) that think it's a good idea. To give you a single experience I had - thread implementation in Zend Optimizer+ in PHP was improved because of GNU Hurd.
 
+Michael Chapman
, actually there is a segment of the discussion the ctte is going through which could be actively harmful.  ctte could mandate a decision in such a way that makes it very difficult for maintainers of packages from explicitly requiring things that only systemd currently provides. Like logind for example. 

The discussion is a bit tangled,  but by preserving choice of what init to run of the Debian project, the cost could be to directly restrict choices upstream projects and package maintainers can reasonably make on specific technologies to integrate and rely on.

The reality is, systemd is kicking the can forward in a large useful leap.  Software higher up the stack is already starting depending on what it provides to make functionality work (logind as a first example).  And none of the other alternative inits are making any effort to provide replacement implementations for the new abilities provided by the systemd userspace.  Trying to hold upstreams hostage via Debian policy decisioning to prevent rapid adoption of systemd as upstream dependency to give the other init teams time to catch up will not result in "choice." It just results in stagnation.  The hard reality is none of the other inits have the contributor momentum to provide alternative implementations of the useful APIs systemd is provided for software up the stack. 
 
+Olav Vitters It was opensuse, I don't remember exact version but it was at least one year ago, maybe two, but I saw exactly this message in several places over the internet and the only solution suggested - to remove systemd.
 
+Olav Vitters I have some experience with pulseaudio - for some years the only working solution to have working skype was "apt-get remove pulseaudio". A year ago the only solution to have daemon's output without going to read the log itself was whatever command that was to remove systemd. The idea is probably right in both cases - pulseaudio and systemd. Implementation in both cases was broken. I don't see any advantages for both pulseaudio and systemd (yes, it might save a few seconds during the boot time on the server, but only RAID initialization takes few minutes and uptime us usually measured on months anyway). But I've experienced plenty of disadvantages. If it's not broken - don't fix it. And even if it's broken - make sure that your fix works before trying to push it everywhere.
 
+Michael Baikov: systemd is not about saving a few seconds at boot. Current startup is messy, systemd integrates that. The assumption that stuff will magically work is imo wrong. Pulseaudio was adopted too quickly, but systemd seems to be ok. There are sometimes some issues, not everything is perfect, but you cannot make something bugfree from the start. That's just unrealistic IMO. The more people are using something, the more bugs that will be found.
 
The upstart position WRT portability and reuse is wrong, BTW. Their proponents basically say that using upstart + parts of systemd work. At the same time, they argue that upstart can be ported to Debian's non-Linux port, completely forgetting that they would have to re-implement everything used of systemd in order to get this portability.

So, given that, it only makes sense to use systemd for Linux, as upstart + parts of systemd is not more portable than systemd itself. And keep the non-linux port at sysvinit at a reduced best-effort support level.
 
+Lennart Poettering +Antoine Martin Not that you guys haven't thought of it yet, but is there anything systemd could do to make it clearer that something is stuck during boot up and provide guidance on how to start to resolve it? I mean most people would start to worry if something was stuck for a handful of seconds but I think someone posed the same question at a systemd Q&A on a video I watched where they mentioned something like a 10 minute timeout.
 
+Matthias Urlichs It's interesting... so Bdale's vote count as 2 because he's the chairman, isn't it?
So, if the things don't change, we will have systemd as default initsystem for Debin Linux... it's pretty unbelievable to me, considering that the race started with (systemd-Upstart) 0-3 from the first minute! Also, if we add to that even the problem of the non-linux port... well, I'm not an expert about init system, but it looks like systemd has very strong technical advantages on Upstart if the race became 5-4 from 0-3!
Add a comment...