Yep. He and the ConsoleKit inventor gave the project to Canonical/Ubuntu under the lead of Martin Pitt. You can find the handover mail in the CK mail list archive (it is one of the last mails :-)

Canonical however, decided not develop CK in the end but made "systemd-shim" instead; at first a fork, but later an attempt to clone systemd-logind. Martin Pitt leads that project now.

There are still a handful of paid developers that support non-systemd infrastructure like systemd-shim and CgManager, but they will stop in the end because all new distro development is going to be systemd only. Then what?

Exactly. But look at all the systemd "system utilities" like systemctl, journalctl, machinectl; they all work exactly like any other first class Linux system tools; they all only do one thing but do it well, they can be piped, they aren't chatty when successful (and actually care a lot about exit codes), aren't interactive etc, care about text output formatting (turn off legends etc) so they are perfectly scribtable.

The point is that all the systemd tools are doing everything expected by system tools according to "Unix philosophy".

I must say I can't see a reasonable use case for this. Sounds racy in all circumstances.

Take a look on these discussions;
http://www.spinics.net/lists/l...

http://lists.freedesktop.org/a...

Basically, systemd requires manual intervention to allow to boot btrfs arrays with both /a missing disk/ and in /degraded mode/
Not a bad default really.

Anyway, in order to allow btrfs to automatically boot in degraded mode with missing disks, and doing it /correctly/ you need some extra module/script/daemon to handle it, since neither the kernel nor systemd (udev) have any knowledge about the internal state of btrfs. Nothing new in that, raid etc. have always been handled by such a daemon. I think that if you use mdadm with btrfs raid, you can automatically mount degraded mode arrays. The critical point is the timeout timer; a crude method that needs to be set according to the particular array in question.
Bringing up a degraded array as RW risk killing the whole array, so it is not something to be done just because a drive is late at appearing.

http://git.neil.brown.name/git...

Isn't that all you need to know to find the error?
Also, use the "-x" with journalctl, it may give further info to generic error messages and even link to more info.

Anyway, systemd have excellent debugging facilities; try to turn on debugging ("kill -56 1" from the CLI, or by setting "MaxLevelKMsg=debug
MaxLevelConsole=debug" in "/etc/systemd/journald.conf" and restart (journald or the VM)

If you read the above discussions, you will find that there is no right solution for all; doing brute force attempts to mount missing drives or bring up raid arrays even though they may not be complete yet (a late drive will make the array degraded) have its own sets of problems, and differs whether it is a two drive or a 1024 drive array. Also, it is not up to either systemd or udev to know about complicated raid states; that should be handled by the raid array software/daemon who can probe internal logic and then inform init what to do (or rely on crude timers).

So this seems more like a RFE than any serious bug. Yes, I can see a use case for automatically booting degraded arrays, but it shouldn't be a default, but an explicit setting of the admin, since only the admin can evaluate risks and knows how much redundancy there is etc.

I think we agree somewhat here; yes such a program could be used with any init, and just like systemd, used on a case to case basis.
My point was that the existing inertia prevented the making and adoption of such program. With systemd there is no longer any reason for not implementing such a helper program in conjunction other init systems and platforms.

In fact, I think the non-systemd platforms should clone as many of the easy implemented features of systemd as possible; that would help upstream projects a lot.

I actually think that the BSD's will develop a systemd clone before the decade is over. Some groups have already started implementing small compatibility layers (systemBSD), others are experimenting with systemd code in order to reverse engineer it for BSD (Uselessd).

Really, over the next couple of years when people actually are starting to "get" systemd, the old ways of doing things with init-scripts etc, will seem very dated.

Appeal to authority is actually a good argument, if it wasn't then it was because heart surgeons knew nothing better about heart surgery than any random ordinary citizen. The CV's of many leading systemd developers is quite impressive.

Lennart Poettering is well aware of how Unix works and "Unix Philosophy". In fact it is sometimes a complaint against systemd that eg. that the systemd tools aren't chatty when successful ("systemctl start daemon" only provides feedback if there is a problem, just like "cp", "mv" etc), or in this case, the handling of a broken fstab.

That people use a rather cartoonish interpretation of what Unix Philosophy is to attack systemd, is another matter. That everything should be small single-function programs piped together with a text-only interface, simply isn't the case for the vast majority of Linux and Unix programs. It is a design ideal that no one really follows for anything remotely complicated. Even Vim isn't correctly designed by this cartoonish interpretation of Unix Philosophy.

No, systemd _abstracts_ away the complexity like a high level API, thereby making advanced features easier to use. cgroups, capabilities(7) and name spaces are normally really complex features to use, thereby making it error prone. systemd makes it easy (no code involved, just key=value in text config files) to use.

And a single point of failure is often much preferred to having multiple points of failure, since it is much easier to harden and secure one point than hundreds. Like in the case of privilege dropping; having hundreds of implementations of hard to write security sensitive code, increases both the attack surface and the potential number of bugs dramatically. Reviewing hundreds of projects each written in their own style, is also much harder.

Nothing prevents other Unix like systems in implementing similar features.
In this case it would probably make the daemons much more portable across systems since they no longer need to care about how privilege dropping works on a particular system, but leave it all to the init system. It will also make the open source world more secure.

Perhaps. I suspect that the reason why such a feature never was developed was the usual catch 22: such a feature would change how init worked, making it incompatible with other init systems. Since no one could lead such a change, everything remained the same.

Now systemd have taken the lead and if other init systems care, they can now implement such a feature while remaining compatible with all major Linux distros.

Beauty is of course in the eye of the beholder, but perhaps your perception of systemd isn't without prejudice; many of the core systemd developers a really experienced Linux developers with deep expert knowledge about various aspects of low level system design.
You may not like how systemd handles fstab errors, but it is done strictly according to "Unix philosophy", which the systemd developers like Lennart Poettering actually know a lot about.

Oh, there are several. RH's for one lead by Florian Weimer, the Coverty project, and probably many white hat (and black hat) security groups; there is prestige in finding a systemd security bug.
There is also a lot of systemd developers, so internally there are "many eyes" watching the code. Also, industry interest groups like the IVI automotive group, Samsung (Tizen etc) and several others are using and developing it outside the core systemd group, and are working with deep security aspects of it. All in all, systemd probably only have the Linux kernel as rival when it comes to code review and inspection.

SysVinit isn't designed by the "KISS principle". Sure it has almost no functionality and have problems even with even basic init tasks, but that doesn't make it KISS designed, simply because SysVinit doesn't avoid code complexity and code duplication; it just pushes the complexity into the daemons instead of dealing with the problems.

Case in point; SysVinit demands that each and every daemon implements code for dropping privileges if they e.g. need a low port number. That makes SysVinit simpler, but it also means that each and every such daemon must implement such low level, system specific, error prone and security sensitive code. Such code have historically often been exploitable.

systemd acts like a proper init system, and offers a single, centralized solution that every daemon that needs to drop privileges can use. That means that experts can implement this single code base, and it can be thoroughly tested, reviewed and debugged, instead of 100's of different projects implementing this feature, over and over again. This is much more system design by the KISS principle than the SysVinit way of doing things.

The point isn't so much that systemd daemons can be made much safer than SysVinit daemons, but that SysVinit setups are actually much more complex and obscure than systemd setups, the complexity is just showed over to the daemon side.

You are absolutely right. Notice how the systemd haters are abusing the moderation system by modding you "flamebait", probably while posting as AC's too.

The systemd haters are a toxic bunch that uses online bullying instead of technical arguments. Wasting time attacking open source developers and open source projects instead of coding an alternative to systemd is exactly why they have been routed from every major Linux distro.

There is firm backing behind systemd as default init system in Debian. There probably also is a lot of willingness to support more than one init system.

The problem with the eternal war by "committee weasels" and "paper warriors" is that it simply shows that continuing supporting SysVinit is the wrong thing to do for Debian, since it will be used as a permanent excuse to feud an eternal war and "retaliate" as you describe it.

At some point Debian will have to make a decision between kicking out SysVinit for good, or live with eternal flame fests on the mailing lists and in the bug tracker. This decision will be forced because of the toxic behavior of the systemd haters.

Wait, wasn't it forced into the OS they use, against the wishes of the bulk of the users?

You systemd haters are simply living in your own delusional world, undisturbed by the harsh realities:
Don't do know that Debian systemd users now outnumber SysVinit users 3-1, even before Debian have released a stable systemd distro?

The vast majority of Linux users that care about init wants systemd, this is why systemd have won a landslide victory in every major Linux distro. Even in Debian the SysVinit faction have failed to mobilize even 5 Debian developers out of 1000 to sponsor a GR to use SysVinit instead of systemd.

You systemd haters are just a tiny, but very vocal and toxic minority in the Linux community. A very good indicator in this is that so many systemd haters like you are logging in as AC's. Another is that that almost all non-systemd development of Linux infrastructure have grinded to a halt. There seems to be almost no Linux developers that support the non-systemd cause.

Sure, keep on attacking open source projects and developers; that will earn you and your fellow travelers exactly what you deserve when it comes to maintaining SysVinit software and getting goodwill at upstream projects.

What you describe isn't the scenario I was trying to describe; you seem to be in total control of the software and can close a bug with impunity; if a user don't like it, they can just go somewhere else.

But imagine you where part of an large organization maintaining a small project. That project used "Library-foo", which just happened to be a target of petty war from a faction: that faction will now see you as an enemy, not because of your project, but because your projects used Lib-foo, instead of Lib-bar. The faction within your organization will then file "political" bugs against your project; each and every time you will have to explain that Lib-bar doesn't have the feature you want and besides simply breaks your software when used in the current version; every time you answer, they will retort with ever more accusations, citing complex internal policy documents, that you have to understand and reject, and then they will slander your project on internal mailing list, claiming that you won't fix bugs and doesn't respond in a timely matter etc. They will then use all the many bugs filed against you and the slandering emails, as evidence of your wrong doings and present their complaints to higher ups in the hierarchy; again you will have to defend yourself, and so on and so on.

In case of Debian, you can also experience a so called "NMU", that means your enemies, if they win the "paper war", can force a patch into your project to support their pet "Lib-bar". Now you have a turd of a patch that leads to feature regression, but you can't really touch it unless the faction will attack you again and again, complaining that your are sabotaging project decisions etc.

In short, a bug tracker is an excellent weapon for "paper war warriors" and "committee weasels". At the moment Debian is experience such a paper war, so it is becoming ever more bureaucratic and top down steered with ever more NMU's that sucks the soul out of the volunteer developers.

Sure, but if that really was the case then it was a bug, most likely a distro bug, or perhaps the OP was impatient and didn't wait 3-5 minutes for daemon timeout.

systemd will always try to boot into "emergency mode" (like Runlevel 1) when fstab is broken It is quite easy to show, just spawn a systemd OS container, edit it's fstab and reboot the container, and watch how you get an emergency shell. A quick glance in the journal will show exactly what went wrong.
Since systemd lives in initramfsf while booting and switches to root when the root-fs is mounted, it will be functional to some degree even if just /boot still works.

systemd is simply designed handle situations correctly that SysVinit simply can't deal with.

Trying to make a virtue out that of the fact that SysVinit is so crude and broken it exposes userland to potential data corruption is just plain denial.

I think you are paranoid in suspecting SysVinit supporters being a front end for Putin/NSA etc. Sure their relentless hate attacks against Linux developers and Linux porjects may look like a concerted effort to split the Linux community, but at least some of them are sincere Linux users, perhaps lacking modern technical insight, but well-meaning never the less.

Yes, the AC's are out in force. The systemd haters do like that because that way they can post hate posts and moderate at the same time. The systemd haters are good at online bullying and trolling, but of course suck when it comes to make a positive contribution.

No. Posix is supported on systemd Linux distros. Doesn't make a difference there.

There are several problems with doing things that way; first of all, its is evident that it isn't uncommon for people to have stale or plain broken fstab entries. This strongly suggest that they are unaware of this, probably because if the system boots, people don't look in the log files. Finding such critical errors in legacy style syslog text logs aren't easy either; if you don't know the nature of the error, it is hard to grep for it.

So exactly because SysVinit cover up such fstab errors, they may remain undiscovered until some other part of the system fails in a noisy matter; at that time irretrievable data loss may have occurred. Allowing such data loss isn't being pragmatic, it is bad practice by any standard.

systemd detects the fstab problem and boots into a special "emergency mode" (like runlevel 1) where the admin can diagnose and fix the problems.
systemd works really well in this regard; a simple "journalctl -b -p err" will find all such errors in the boot process and display them.

It has always been possible to boot into "emergency mode (think Runlevel 1)" if systemd detected a fstab problem, or if there are any such mount point problems from dying disks etc. systemd have several fallback mechanisms depending of the nature of the boot problem.

I think the "work in progress" is about Debian installers detecting obviously bad fstab entries when upgrading, and eg. mark them "nofail" or ask the user to fix the fstab before proceeding.