User: Password:
|
|
Subscribe / Log in / New account

Debian's technical committee starts another init system vote

From:  Ian Jackson <ijackson-AT-chiark.greenend.org.uk>
To:  727708-AT-bugs.debian.org
Subject:  Bug#727708: Call for votes on init system resolution
Date:  Wed, 5 Feb 2014 16:33:57 +0000
Message-ID:  <21234.26613.826545.236142__6375.37207589975$1391618367$gmane$org@chiark.greenend.org.uk>
Archive-link:  Article

Ian Jackson writes ("Bug#727708: package to change init systems"):
> I now intend to do the CFV at 16:30 UTC on Wednesday.

I hereby call for votes on my previously proposed resolution and
amendments.  All the options require a simple majority.

The list of options, and full resolution text, are reproduced below.

Thanks,
Ian.


Options on the ballot:

  DT   systemd default in jessie, requiring specific init is allowed
  DL   systemd default in jessie, requiring specific init NOT allowed

  UT   upstart default in jessie, requiring specific init is allowed
  UL   upstart default in jessie, requiring specific init NOT allowed

  OT   openrc default in jessie, requiring specific init is allowed
  OL   openrc default in jessie, requiring specific init NOT allowed

  VT   sysvinit default in jessie, requiring specific init is allowed
  VL   sysvinit default in jessie, requiring specific init NOT allowed

  GR   project should decide via GR

  FD   further discussion

== version D (systemD) ==

   The default init system for Linux architectures in jessie should
   be systemd.

== version U (Upstart) ==

   The default init system for Linux architectures in jessie should
   be upstart.

== version O (Openrc) ==

   The default init system for Linux architectures in jessie should
   be openrc.

== version V (sysVinit) ==

   The default init system for Linux architectures in jessie should
   be sysvinit (no change).

== version GR (General Resolution) ==

   The Technical Committee requests that the project decide the
   default init system for jessie by means of General Resolution.

== clarification text for all versions except GR ==

   This decision is limited to selecting a default initsystem for
   jessie.  We expect that Debian will continue to support multiple
   init systems for the foreseeable future; we continue to welcome
   contributions of support for all init systems.

   Therefore, for jessie and later releases:

== dependencies rider version T (Tight coupling) ==

   Software may require a specific init system to be pid 1.

   However, where feasible, software should interoperate with
   all init systems; maintainers are encouraged to accept
   technically sound patches to enable interoperation, even if it
   results in degraded operation while running under the init system
   the patch enables interoperation with.

== dependencies rider version L (Loose coupling) ==

   Software outside of an init system's implementation may not require
   a specific init system to be pid 1, although degraded operation is
   tolerable.

   Maintainers are encouraged to accept technically sound patches
   to enable improved interoperation with various init systems.

== rider for all versions except GR ==

   This decision is automatically vacated by any contrary General
   Resolution which passes by a simple majority.  In that case the
   General Resolution takes effect and the whole of this TC resolution
   is to be taken as withdrawn by the TC, just as if the TC had
   explicitly withdrawn it by a subsequent TC resolution.

-- 




(Log in to post comments)

Debian's technical committee starts another init system vote

Posted Feb 5, 2014 17:13 UTC (Wed) by theophrastus (guest, #80847) [Link]

"on what the default init system should be in the upcoming "jessie" release."

(quick curious trivia aside before the usual battle begins)

when i read that quote above i foolishly think: hey, i'm sitting on a 'jessie' release, the ToyStory nomenclature recedes into the past[1], whereas 'stable', 'testing', 'unstable' stay with us incrementing into the future. so how can there be an "upcoming" of an existing meta-release-name? shouldn't that read something like "upcoming -unstable- release"?

[1] see the graph near the bottom of https://wiki.debian.org/DebianReleases

Debian's technical committee starts another init system vote

Posted Feb 5, 2014 17:38 UTC (Wed) by dfsmith (guest, #20302) [Link]

I like how Debian brings out the technical pedantry in people. B-)

Debian's technical committee starts another init system vote

Posted Feb 5, 2014 17:41 UTC (Wed) by theophrastus (guest, #80847) [Link]

i assumed i was reading it wrong out of ignorance (perhaps a new init system was coming barreling down upon my sweet 'jessie') and was seeking enlightenment. little did i suspect i was being a pedantic [wink]

Debian's technical committee starts another init system vote

Posted Feb 5, 2014 17:52 UTC (Wed) by juliank (subscriber, #45896) [Link]

There is (a) jessie (branch), but there is no jessie *release* yet.

Debian's technical committee starts another init system vote

Posted Feb 5, 2014 21:25 UTC (Wed) by drag (subscriber, #31333) [Link]

This.

Ostensibly Testing is the next stabel release, ie: Jessie.

So this vote would apply most strongly to users and developers on testing, unstable, and then experimental.

Debian's technical committee starts another init system vote

Posted Feb 5, 2014 18:19 UTC (Wed) by ovitters (subscriber, #27950) [Link]

And as expected, various Technical Committee members are not addressing anything, just sticking their heads in the sand. Already 3 are voting for "requiring specific init NOT allowed". Which means you are probably forced to rely on the unmaintained ConsoleKit.

The vagueness and stupidity of this all I blogged about, see http://blogs.gnome.org/ovitters/2014/02/03/my-thoughts-on....

Someone at Gentoo said they tried really hard to avoid a dependency on systemd, but eventually could not make it happen. Within Debian they just say "whatever, make it so". This by technical committee members. This is crazy.

Debian's technical committee starts another init system vote

Posted Feb 5, 2014 18:21 UTC (Wed) by drago01 (subscriber, #50715) [Link]

That happens when you mix politics into technical debates.

Debian's technical committee starts another init system vote

Posted Feb 5, 2014 18:44 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

Don't worry, Steve Langasek is already voting to cancel the vote and spend some more time for useless bickering. So for that matter had Andreas Barth.

I predicted a couple of weeks ago that it's going to take 3-4 months for CTTE to decide on something, followed by 3-4 months for a GR (to support SysV).

Debian's technical committee starts another init system vote

Posted Feb 5, 2014 19:12 UTC (Wed) by drago01 (subscriber, #50715) [Link]

Well if "further discussion" is one of the options to vote for why does it cancel the vote? If the majority votes for $something where $something != FD shouldn't this be enough to have a decision?

Debian's technical committee starts another init system vote

Posted Feb 5, 2014 19:52 UTC (Wed) by foom (subscriber, #14868) [Link]

It doesn't technically cancel the vote. But a vote for FD over everything is, in this instance, saying you would like to cancel the ballot.

If at least 4 of the 8 people vote FD above everything else, that'll cause the result of the vote to be FD -- which in this case would be interpreted as voting for canceling the ballot and doing it again with modifications to the set of options.

Debian's technical committee starts another init system vote

Posted Feb 5, 2014 19:41 UTC (Wed) by oldtomas (guest, #72579) [Link]

The vagueness and stupidity of this all [...]

Now, now, ovitters. Practice what you preach. A bit of moderation, please.

Debian's technical committee starts another init system vote

Posted Feb 5, 2014 19:46 UTC (Wed) by ovitters (subscriber, #27950) [Link]

I'm more than a bit frustrated. Many years of *personally* highlighting one issue (out of several). And still no answer. How long should I stay polite and when it is time to say "enough is enough"?

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 12:14 UTC (Thu) by oldtomas (guest, #72579) [Link]

Does that mean that now I am allowed to call out on the systemd angry mob whenever I'm frustrated?

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 12:17 UTC (Thu) by ovitters (subscriber, #27950) [Link]

That means I shouldn't have and you were and are totally right to call me out on it.

It now feels like an echo chamber at LWN. I want different opinions.

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 15:13 UTC (Thu) by oldtomas (guest, #72579) [Link]

Fair enough :-)

I definitely prefer to disagree with you on technical/strategic terms and still hold you in high regard.

Debian's technical committee starts another init system vote

Posted Feb 5, 2014 19:43 UTC (Wed) by foom (subscriber, #14868) [Link]

I think your comment is completely unfair: Steve Langasek, and Ubuntu, are *actually doing work* to implement the D-bus APIs required by Gnome (like logind), without requiring systemd as pid1, as you are well aware (and mention in your blog post in detail).

You may think that's all a silly waste of time to do that, but you cannot call it just "sticking their heads in the sand" and ignoring that gnome needs those things -- they ARE doing the work to allow gnome to have the D-Bus APIs it requires without using systemd pid1.

I expect the tech-ctte members voting that way are worried that the gnome debian team will reject all patches to support non-systemd pid1 if systemd is selected as default, and thus, want to make it clear that it's a Requirement that the maintainer must support other init systems (that is to say: upstart).

Debian's technical committee starts another init system vote

Posted Feb 5, 2014 19:52 UTC (Wed) by ovitters (subscriber, #27950) [Link]

Then you skipped the bits in the blog where I said it is unrealistic. If that other one doesn't work everywhere it *cannot* be used. If logind has a new feature (and it will, they're adding that vt switching stuff), you cannot upgrade.

Now Debian/Hurd at the moment uses a different init system just for them. The logind bit that Canonical forked won't work on Debian/Hurd: result: cannot rely on logind.

The current wording makes it impossible to rely on logind or the Canonical forked version of logind.

I also mentioned in my blog that our GUI for the Journal now cannot be packaged by Debian by this wording. I think I can back up everything that I'm stating.

Debian's technical committee starts another init system vote

Posted Feb 5, 2014 21:06 UTC (Wed) by foom (subscriber, #14868) [Link]

Firstly: it doesn't say you can't make packages architecture specific. So, if the init-system-agnostic forked-logind doesn't work on Debian/Hurd, that's okay. You're still init-system-agnostic, just not architecture agnostic.

Secondly I don't think it's unrealistic to decide that it is an release-critical bug if the Gnome desktop fails to work on non-systemd-pid1, AS LONG AS there are people willing to write the code to make it work. Yes, that means a gnome upgrade may be blocked on upgrading the forked-logind package to have the new capabilities it requires. And, of course, this is only an acceptable requirement if forked-logind gets updated in a timely manner, so that upgrades to Gnome aren't held up for long periods of time. (Which is certainly worth worrying about -- but it doesn't seem obviously unrealistic.)

As to your Journal GUI issue: yes, that's an issue. Your points in your blog about how it makes no sense to cover everything equally with a broad brush are exactly right. (I highly suspect the ctte members voting on this are actually thinking "core packages like the default desktop" when they say "software".)

That said, this vote isn't a vote on forcing a maintainer to do something. A dispute that requires overriding a maintainer would be a separate vote, and require a super-majority.

So, to upload Gnome Logs if this vote passes, I'd suggest either:
1) "Declare" Gnome Logs part of Gnome, therefore it failing to work is simply degraded functionality of GNOME, not separate software that requires systemd. (note that it says "software", not "package").
2) Decide that "degraded functionality" is showing you no log data because journald isn't running and that's the only source of log data it knows about. :)

And see if anyone actually complains...

Debian's technical committee starts another init system vote

Posted Feb 5, 2014 21:37 UTC (Wed) by drag (subscriber, #31333) [Link]

All of that seems like a huge amount of thought and effort spent on making the system dramatically inferior to one that could exist if Debian just choose a init system and stuck to it.

Debian's technical committee starts another init system vote

Posted Feb 5, 2014 22:13 UTC (Wed) by dlang (subscriber, #313) [Link]

> All of that seems like a huge amount of thought and effort spent on making the system dramatically inferior to one that could exist if Debian just choose a init system and stuck to it.

as long as they choose the init system that you want. If they choose an init system that you don't want, you won't want them to stick to it.

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 13:51 UTC (Thu) by drag (subscriber, #31333) [Link]

> as long as they choose the init system that you want. If they choose an init system that you don't want, you won't want them to stick to it.

I've said plenty times in the past that they would be far better off just sticking to something like sysvinit then trying to support different init options. Down that path lies insanity.

Choosing to support multiple init systems is the worst possible choice Debian could make.

Debian's technical committee starts another init system vote

Posted Feb 5, 2014 23:58 UTC (Wed) by foom (subscriber, #14868) [Link]

Oh yeah. Certainly I'd prefer if Debian would:
1. choose systemd default for Linux, it's clearly the best choice, technically.
2. allow other init system packages to exist as options. Debian has historically had the policy of inclusionism: let it continue here, somewhat.
3. require the core boot and server task packages to continue working with sysvinit
4. allow other packages to depend on systemd if their maintainers desire. In particular, gnome may depend on systemd.
4b. stop pretending that gnome on debian kfreebsd or hurd is actually useful to anyone.

But that doesn't mean it's unrealistic to do otherwise, it's just a poor use of the project's resources, and a poor decision.

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 13:59 UTC (Thu) by drag (subscriber, #31333) [Link]

I think that it's far more important for a operating system to focus on simplicity and correct functionality at the low levels then offer choice for choice's sake. What happens otherwise is that you end up with a massive increase in complexity that puts a much higher burden on maintainers and end users without any sort of tangible benefits.

Sure it's nice to be able to explore different technical options, but these init systems have been around for a long time now. The youngest one is 4 years old. Upstart is nearly 8.

Does the software have to be decades old before Debian decides that they can depend on it?

Maybe Debian should not be content to just depending on GNU? Maybe they should offer the choice of stripping all that out and replacing it with the userland utilities from NetBSD? That seems pretty inclusive to me.

Debian's technical committee starts another init system vote

Posted Feb 5, 2014 23:42 UTC (Wed) by ewan (subscriber, #5533) [Link]

"Firstly: it doesn't say you can't make packages architecture specific. So, if the init-system-agnostic forked-logind doesn't work on Debian/Hurd, that's okay. You're still init-system-agnostic, just not architecture agnostic."

But pretty much the key argument against just relying on systemd is that it's kernel specific. There's no benefit is avoiding a dependency on one Linux specific bit of infrastructure only to depend on another one.

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 0:00 UTC (Thu) by foom (subscriber, #14868) [Link]

Ehhh, portability is a convenient justification for preferring upstart, not a reason.

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 12:15 UTC (Thu) by ovitters (subscriber, #27950) [Link]

Thanks for the detailed answer! I don't understand a few things, so would appreciate some further clarification.

I think both options in the vote basically say the minimum guidelines is that maintainers should not block any compatibility patches unless they have a good reason to do so. As long as the majority of these patches are with the people who want/need/advocate it, then a small amount of effort on the package maintainer should be something you can expect.

I don't understand your comments though. It seems like package maintainers could still partly ignore the outcome?

e.g.:
> That said, this vote isn't a vote on forcing a maintainer to do something.

I think this vote exactly does that. I think it is unacceptable for a package maintainer to block something unless they have a good reason (not liking portability/Upstart/systemd/etc is not one of them).

With not allowing to depend on anything that might be systemd specific (because that's the rule in practice anyway), you're moving the distribution at the slowest pace possible. Meaning: you're consciously slowing everything down. This while the development pace is different.

Things shouldn't break on purpose, churn for non-technical reasons (e.g. LLVM seems to cause churn to ensure companies upstream their changes) is something that should not happen. But slowing things down on purpose is just plain weird.

Now you said something else:
> I don't think it's unrealistic to decide that it is an release-critical
> bug if the Gnome desktop fails to work on non-systemd-pid1, AS LONG AS
> there are people willing to write the code to make it work

But CTTE vote doesn't have anything like you said in it. I'd expect a release critical bug to show up to *add* support. Not to prevent any work from happening.

Anyway, that's how I see it. POSIX and so on change, they have new versions, etc. Any software as well. Waiting on everyone to catch up before being able to continue is a great strategy to not go anywhere.

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 12:25 UTC (Thu) by ovitters (subscriber, #27950) [Link]

Colin Watson on logind:
> My interpretation of L is that GNOME may depend on logind (or logind-208
> or whatever) as long as that dependency is declared such that another
> init system can provide it.

Ian Jackson on logind:
> I think the conclusion is that it may not. (This is, after all, the
> heart of the problem.)

They've had loads of talk, etc. But their interpretation of the logind question and what a vote implies is still unclear. While that's one of the major concrete things that should be answered! Why else vote?

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 15:48 UTC (Thu) by anselm (subscriber, #2796) [Link]

The problem is really that the Upstart proponents are desperately trying to prevent a situation where (a) systemd is the default init system on Debian GNU/Linux, and (b) it becomes OK for packages to depend on the presence of the default init system. If systemd does become the default, then other packages must at all costs be forbidden to rely on systemd by way of direct dependencies. (The actual wording on the most recent ballot was more general but this is what it amounts to in the end.)

Hence, for example, under this theory the relevant GNOME packages should be forced to depend on a separate package providing whatever it is that GNOME needs from systemd, e.g., logind. This package would then, in theory, be a »virtual« package that can also alternatively be provided by a hypothetical logind-compatible Upstart-based replacement which someone would have to write and maintain. (Many Upstart folks would probably prefer that »someone« to be the Debian GNOME maintainers, under the doctrine that »no package may depend on a specific init system«, but it could be argued that it should in fact be the Upstart people themselves, or indeed anyone who is actively interested in having GNOME run under some other init system than systemd.)

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 15:53 UTC (Thu) by ovitters (subscriber, #27950) [Link]

> This package would then, in theory, be a »virtual« package that can also
> alternatively be provided by a hypothetical logind-compatible

But here the various CTTE members are in disagreement as per latest ctte messages. Colin mentioned that above is totally ok. Ian says until there is an alternative, you cannot just rely on a virtual package. That's clearly to block things and not preferring Debian GNOME package maintainers to do the work, but making it almost impossible for them to do anything until there is a solution.

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 18:53 UTC (Thu) by rodgerd (guest, #58896) [Link]

It's not particularly unclear at all if you follow Ian's posts: he is opposed to allowing init systems to make "facts on the ground"[1]; he would be happy to see anything depend on systemd banned from the archive and relegated to a Debian offshoot distro. It's there in the ctte archives.

[1] A pretty offensive choice of phrases, but whatever.

Debian's technical committee starts another init system vote

Posted Feb 5, 2014 22:13 UTC (Wed) by javispedro (subscriber, #83660) [Link]

Oh, if only this journal thing did not so tightly depend on systemd for no apparent reason...

Debian's technical committee starts another init system vote

Posted Feb 5, 2014 22:15 UTC (Wed) by dlang (subscriber, #313) [Link]

and if only systemd didn't require this particular implementation of logging for no apparent reason...

Debian's technical committee starts another init system vote

Posted Feb 5, 2014 22:27 UTC (Wed) by smurf (subscriber, #17840) [Link]

Well, you're free to fork the thing and rewrite the salient bits so that it works with upstart. Yet another couple of man-weeks burned because somebody doesn't like systemd, but then that's your problem, not mine.

Anyway, there is one reason for the tight coupling. The systemd people think (with some justification IMHO) that their PID 1 _will_ run, so they might as well depend on it and make their life easier.

Debian's technical committee starts another init system vote

Posted Feb 5, 2014 22:54 UTC (Wed) by javispedro (subscriber, #83660) [Link]

By that logic, the systemd people may someday think that GDM/KDM _is_ the universal session manager and tie their logging framework to it. It works for them, after all. Or that Linux is the universal kernel and tie their init+logging+everything framework to it.... Wait, that already happened.

While "they just didn't feel like interoperating" is a perfectly valid excuse in the FOSS world (volunteers!), it is also not a technical argument. I can easily see how a "universal operating system"'s governing board might decide to not accept such argument.

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 2:00 UTC (Thu) by droundy (subscriber, #4559) [Link]

I thought there was also a valid security reason for Journal to be coupled to systemd: it is designed so to ensure that log entries are related to the service that created them, and without init system involvement, this doesn't sound possible. (Note: this is a vague memory, so please correct me if I'm wrong.)

Debian's technical committee starts another init system vote

Posted Feb 7, 2014 7:42 UTC (Fri) by dlang (subscriber, #313) [Link]

there are two possible methods for coupling the log entries to the process by the init system

1. filesystem trickery so that every service writes to /dev/log, but it's really a different /dev/log

2. use SCM_CREDENTIALS to ask the kernel who is on the other side of the /dev/log socket

#2 was already being discussed before the journal was released, and it's implemented in multiple syslog daemons, no need for a dependency on init.

#1 requires that init prepare the environment for the service before it starts, but that doesn't mean that the thing listening to /dev/log needs to be part of the init system. it just needs a way to request another /dev/log socket be created

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 13:38 UTC (Thu) by ovitters (subscriber, #27950) [Link]

> By that logic, the systemd people may someday think that GDM/KDM _is_
> the universal session manager and tie their logging framework to it.

systemd people do no such thing. GNOME GDM maintainer has allowed GDM to log into the Journal (OPTIONALLY!). Now we're writing a GUI to make the various entries from the Journal visible.

Why? Technical reasons! We want to link the stderr+stdout output of any application back into the Journal, then being able to display it. With the Journal (+ user session) we (=GNOME) could have that.

This means making a pretty hidden bit of Linux/UNIX more visible. And making it easy at the same time. Show the application which generated the output.

Obviously you could implement everything the Journal does within GNOME and add yet another layer of abstraction. But IMO easier to depend OPTIONALLY on the Journal.

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 17:42 UTC (Thu) by ebassi (subscriber, #54855) [Link]

there's a reason why systemd uses the journal: you really want an expressive log of what happens during the boot process; and if the init system has a logging facility already, then it stands to reason that the logging facility should be provided to the whole system, both directly through API and indirectly through intercepting stdout and stderr from the daemons that the init system spawns.

as the person that used to maintain the old GUI around system logs in GNOME 2.x, I can tell you that I would have paid to get something like the journal, instead of all the custom log files that I had to parse. I even had to accept a patch from a Sun developer who wanted to get plugins inside the log viewer application so that he could munge the log files on Solaris. also, parsing custom text to group by day/month, and extracting time stamps that are never the same is a mess; getting a consistent output is basically impossible.

I'm truly happy not to maintain that crud any more, and I'm also happy that GNOME will have a decent system log viewer showing events from the early boot sequence down to the current event, with the ability to dynamically filter events, and the ability to have more data attached to an event than just text that needs to be parsed by ad hoc tools that inevitably go out of sync.

Debian's technical committee starts another init system vote

Posted Feb 7, 2014 13:33 UTC (Fri) by jubal (subscriber, #67202) [Link]

There are quite well understood performance reasons for why journald should be an /optional/ component on any server system that's supposed to forward logs to a remote logging sink.

There's a difference between /work reasonably on my laptop with an ssd drive/ and /send the server logs outside as quickly as possible/.

Debian's technical committee starts another init system vote

Posted Feb 7, 2014 16:55 UTC (Fri) by fandingo (subscriber, #67019) [Link]

Zuki, a commenter here, originally wrote a remote logging feature for the journal back in 2012, but unfortunately, he wasn't able to get it finished up and merged. As of last week, it sounds like he's going to have some time to get it finished.

If systemd has native remote send/receive that should remedy this complaint entirely as there won't be any journal->syslog->network->syslog path anymore.

Debian's technical committee starts another init system vote

Posted Feb 5, 2014 22:14 UTC (Wed) by jordi (subscriber, #14325) [Link]

> I expect the tech-ctte members voting that way are worried that the gnome debian team will reject all patches to support non-systemd pid1 if systemd is selected as default, and thus, want to make it clear that it's a Requirement that the maintainer must support other init systems (that is to say: upstart).

I can't stop wondering why some tech-ctte members think the GNOME team would do that. It's not like we didn't spend countless hours trying to accomodate kFreeBSD in the past, just because it's a release architecture (this means, lots of special-casing for packages depending on Linux-only features, patching GNOME shell here and there to make NM bits optional, and a long list of other bits).

I fear, as pointed in a subthread below, that a first version of a patch for !systemd support might come along and be happily applied by us, and then we are stuck with a bitrotten patchset when trying to upgrade to GNOME 3.14 or some other future release, while the original patch author has other things to do while doing $paidwork.

I seriously doubt this is going to work on the long term, and that's why I think the ballot options forbidding dependencies are a recipe for disaster.

Debian's technical committee starts another init system vote

Posted Feb 5, 2014 22:31 UTC (Wed) by smurf (subscriber, #17840) [Link]

If they manage to select systemd as the default, then I'd quietly assume that any software that requires systemd would be OK.

No such problem exists with upstart, of course, as there simply are no relevant features to depend on.

Debian's technical committee starts another init system vote

Posted Feb 5, 2014 23:30 UTC (Wed) by jordi (subscriber, #14325) [Link]

> If they manage to select systemd as the default, then I'd quietly assume that any software that requires systemd would be OK.

I think you're assuming too much there. The CTTE members favouring the "dependencies not allowed" variants have stated that whichever init system is default would not change the rule to not being able to explicitly depend on one. IOW, GNOME would not be able to add a dependency on systemd-as-pid1 (aka systemd-sysv), and thus would need to carry patches, should they be posted, in order to accomodate other init systems.

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 7:49 UTC (Thu) by josh (subscriber, #17465) [Link]

The worse problem is the implied requirement to carry patches *that do not yet exist* to accommodate other init systems.

As well as the highly likely scenario of making the experience with systemd suboptimal in the process of attempting to accommodate those other init systems, which seems quite probable in the first iteration of such patches.

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 6:56 UTC (Thu) by Duncan (guest, #6647) [Link]

> Already 3 are voting for "requiring specific init NOT allowed". Which means you are probably forced to rely on the unmaintained ConsoleKit.

> Someone at Gentoo said they tried really hard to avoid a dependency on systemd, but eventually could not make it happen. Within Debian they just say "whatever, make it so". This by technical committee members. This is crazy.

How is "requiring specific init not allowed" forcing consolekit? The wording specifically /does/ allow degraded operation with secondary inits, and it's certainly possible to have a desktop without systemd OR consolekit (or polkit or...). I know that as I'm doing that here, with kde, which unlike gnome has a policy of not hard-deping on systemd.

Sure I lose a bunch of superfluous functionality like automount and GUI user editing of deep system config settings if I turn off the consolekit/systemd/polkit/whatever requiring options, but some of us consider those security-suspect mal-features in the first place, and it's certainly /possible/ to do without them, and even for those who consider that "degraded" operation, what's the problem, since the resolution wording specifically allows for such "degraded" operation under upstream-non-preferred init systems?

And if gnome makes it so difficult to not tie to systemd that it's impossible to do without, well, that's upstream's decision, and if it means a distro can't officially carry it due to distro policy, so be it. Put gnome in some unofficial repo somewhere where it can have whatever deps it wishes instead of the main debian repo, and be done with it. Optionally, carry a hacked up gnome with part of its functionality removed in ordered to comply with the distro policy in the official tree, but that's entirely optional. Either way, linux users (including debian users) have already become used to enabling alternative repos if they want software with specific features enabled, due to legal or policy reasons, and this won't change any of that. People (or offshoot distros) who want systemd-required gnome bad enough will enable the alternative repo; people who prefer to stick with policy-approved versions won't, and life will go on.

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 7:19 UTC (Thu) by raven667 (subscriber, #5198) [Link]

> turn off the consolekit/systemd/polkit/whatever requiring options, but some of us consider those security-suspect mal-features in the first place,

I don't know all of the technical problems which these tools were created to solve, but I'm pretty sure you don't know either. There have been many (hackish) attempts to solve the multi-seat problems and there are apparently a ton of weird corner cases in VT switching between multiple users which was the reason ConsoleKit was created. The fact is that ConsoleKit is now unmaintained because all of the developers are working on systemd-logind which does everything the old system did and more. Not using those tools means that either you re-implement what they are doing your self or you are going to be a victim of weird corner cases which the standard tools fix.

Debian's technical committee starts another init system vote

Posted Feb 7, 2014 13:51 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

I know that if you login on a TTY and use startx, you need ConsoleKit or logind to get PulseAudio to work because your VT doesn't match your login VT. I think the use case for such things is that PulseAudio will mute (pause?) streams when on another user's VT.

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 7:52 UTC (Thu) by josh (subscriber, #17465) [Link]

> Sure I lose a bunch of superfluous functionality like automount and GUI user editing of deep system config settings if I turn off the consolekit/systemd/polkit/whatever requiring options

First of all, in most cases no such "options" exist unless someone takes the time to write them. Don't belittle the huge amount even offering such options would require.

Second, how about "superfluous" features like the ability to suspend/hibernate/resume, or connect to a network, or eventually to run gnome-session at all?

Debian's technical committee starts another init system vote

Posted Feb 12, 2014 18:01 UTC (Wed) by ThomasBellman (subscriber, #67902) [Link]

I'm not Duncan, but:

> Second, how about "superfluous" features like the ability to suspend/hibernate/resume,

Not very important to me at least. My laptops I usually power off when I need to pack them in a bag; workstations and servers I let run all the time. And I know I have in the past managed to do suspend and resume without having either ConsoleKit or systemd-logind installed (I *think* I used pm-suspend to tell the kernel to suspend).

> or connect to a network,

'ifup eth0' works perfectly in at least Fedora and CentOS, and '/etc/init.d/net.eth0 start' in Gentoo. Likewise for 802.11 network interfaces; the Gentoo way even starts wpa_supplicant automatically (in Fedora I need to start it separately).

> or eventually to run gnome-session at all?

Can't comment on that, since I don't use Gnome myself.

Debian's technical committee starts another init system vote

Posted Feb 12, 2014 22:15 UTC (Wed) by vonbrand (guest, #4458) [Link]

I prefer to have the machine suspend properly in the (rare) cases I use it. OK, thanks to systemd this Fedora boots fast enough it is no real matter. And having it automatically get the Ethernet (or WiFi if I'm not in my office) at work or only WiFi at home without having to log in as root and fiddle around is priceless.

Debian's technical committee starts another init system vote

Posted Feb 12, 2014 22:24 UTC (Wed) by rodgerd (guest, #58896) [Link]

> Not very important to me at least.

I think the number of people who consider reliable suspend/hibernate on laptops to be unimportant is much, much smaller than the ones who do. Who knows, perhaps I'm wrong.

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 9:13 UTC (Thu) by smurf (subscriber, #17840) [Link]

It's certainly possible, at least for now, to build Gnome with ConsoleKit and have some sort of degraded operation.

It is however, TTBOMK, not possible to decide at runtime. So Debian would have to ship two versions of some core Gnome components.

This would be a maintainer's worst nightmare.

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 10:00 UTC (Thu) by hummassa (subscriber, #307) [Link]

Why? It's just a case of half a dozen #ifdefs and two different binary packages generated from the same source. It seems rather simple to me.

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 10:06 UTC (Thu) by fmuellner (subscriber, #70150) [Link]

Whether logind or ConsoleKit (or nothing[*]) is used is a runtime decision, so no extra binaries required. Other features like integration with systemd's journal are compile-time options, but it should be possible to enable those and still run on non-systemd systems.

[*] Some ConsoleKit features require old versions of UPower and will degrade to not using anything if a newer version of UPower is used

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 11:06 UTC (Thu) by ovitters (subscriber, #27950) [Link]

> It is however, TTBOMK, not possible to decide at runtime.

We did initially only partly (due to lack of time and IMO runtime selection is kind of mad). Gentoo provided lots of fixes for this during IIRC 3.6 timeframe or maybe earlier. At that stage I assume it was pretty good. We're now in the development of 3.12 and Gentoo switched to relying on systemd for GNOME 3.8. So it should still be possible, but it might be terribly buggy (IMO things need to be tested and those bits have been touched, moved around, etc).

I found that runtime fallback thing to be buggy while relying on that at Mageia. Not sure of the cause, maybe GNOME, maybe other components.

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 15:28 UTC (Thu) by fmuellner (subscriber, #70150) [Link]

IMO runtime selection is kind of mad

It's actually not that bad - it boils down to checking once whether a certain runtime file exists and picking either the systemd or fallback implementation of a common interface according to the result. All a compile-time switch would do is turn the file check into an #ifdef, which doesn't reduce code complexity much - in fact, in cases of optional components like logind, a runtime check is a good idea in any case. I can't think of any reason why someone would want to "systemctl disable systemd-logind" other than the desire to shoot oneself in the foot, but it's still an option that needs to be taken into account IMHO ...

I found that runtime fallback thing to be buggy while relying on that at Mageia.

By now the fallback thingie is only used by the BSDs and unstable (testing?) Debian systems without systemd, at least as far as I can tell - that's fairly close to untested, and unlikely to improve. In the long run I expect GNOME to just plainly disable functionality if the underlying OS does not offer the corresponding interfaces. This explicitly puts the burden of providing those interfaces on those who can't or don't want to use systemd, but in practice that is already the case for the bitrotting ConsoleKit path.

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 9:14 UTC (Thu) by ovitters (subscriber, #27950) [Link]

> How is "requiring specific init not allowed" forcing consolekit?

Because only ConsoleKit is agnostic of init system. The logind fork is not, it still will assume that it can manage the cgroup structure. If I was a developer I'd just mess with things and write an init system that hides cgroups for itself so the logind fork cannot work at all. Claim it is for security or something :-P

> The wording specifically /does/ allow degraded operation with secondary
> inits, and it's certainly possible to have a desktop without systemd OR
> consolekit (or polkit or...).

We say we need logind and ConsoleKit is unmaintained. We relied on ConsoleKit for years. I've gotten the "you don't need it then" answer quite a few times, but that's not realistic.

> And if gnome makes it so difficult to not tie to systemd that it's
> impossible to do without, well, that's upstream's decision, and if it
> means a distro can't officially carry it due to distro policy, so be it.

We're not making it difficult. For various things there is only one implementation, or it is totally unmaintained. How's that our problem? You can work on alternative implementations.

What is being done by these CTTE members is forcing that everything should have an alternative implementations. That's not a policy, that is directing upstream without being reasonable.

We do try and ensure things could be implementable differently. Patches are ok. What is NOT ok is demanding multiple implementations. If you want such work done, do it!

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 14:02 UTC (Thu) by krake (subscriber, #55996) [Link]

> "requiring specific init NOT allowed". Which means you are probably forced to rely on the unmaintained ConsoleKit.

Isn't that conclusion only true if logind depends on one specific implementation of systemd AND that implementation depends on running as the init system?

I.e. are the operations required by logind access restricted inside the kernel so that only the process with PID 1 can successfully invoke them?

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 14:10 UTC (Thu) by ovitters (subscriber, #27950) [Link]

To me it is totally unclear what they mean. I've quoted the opinions of two CTTE members who voted for "loose coupling" and the explanations are conflicting.

So you're assuming that if at least two init systems provide this functionality, then it is ok. I don't see this written down. It says you cannot depend. Not depending for me is clear cut: no dependency. Not depending on one, not two, not multiple, none. As soon as you introduce an init system which cannot work together with functionality a package is relying on: too bad, remove the functionality (if possible). Anyway, this is how I read the "loose coupling" and it seems that one person voting for it agrees, while the other sees it differently.

For the logind fork, Lennart mentioned that with the planned cgroup changes, the init systemd should be the same as the one managing cgroup. Anything else would contain subtle bugs (races, etc). What Canonical is planning with the fork is exactly that. Jef Spaleta explained the various existing design bugs in Upstart. So I do think this fork will work, but it'll have it fair share or similar design issues. I'm not super technical though, so I have to rely on people arguing technically and then reading about it.

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 14:25 UTC (Thu) by krake (subscriber, #55996) [Link]

I am not clear on the technical low level details either, hence me asking.

My rather limited understanding of cgroups is that it is a feature provided by the Linux kernel and accessed and/or managed through systemd.

Since that always comes up in the context of init process I assume that the kernel system calls related to cgroups cannot be executed by any other process.

I mean, it must be something that the kernel enforces, otherwise any init system could just run systemd and all its dependents would have their requirements met.

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 14:35 UTC (Thu) by ovitters (subscriber, #27950) [Link]

Oh, that I know and can explain. Cgroups can be managed currently via the filesystem. However, that allows way too much. In future, the kernel people just want one process to manage it. So systemd implemented something to allow this to happen. According to systemd, this should be tied together. Others are working on alternative cgroup managers.

So this is all to ensure that in future things will be done differently.

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 14:50 UTC (Thu) by krake (subscriber, #55996) [Link]

> Others are working on alternative cgroup managers.

Given that apparently only PID 1 can (or will be able to) access the cgroup kernel feature that sounds like a wasteful thing to do.

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 14:57 UTC (Thu) by ovitters (subscriber, #27950) [Link]

No, that is something Lennart things is the only solution. But you could separate. The kernel people only want one managing it. According to Lennart (+rest of systemd) anything other than integrated means subtle bugs. But you could live with that and/or ignore it.

This IIRC, if I'm wrong then happy to hear.

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 15:06 UTC (Thu) by krake (subscriber, #55996) [Link]

So it is more a recommended than a required thing?

I.e. anyone using a different init could just run systemd early on? Wouldn't that make the whole "depends on an init system" discussion moot?

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 18:01 UTC (Thu) by fandingo (subscriber, #67019) [Link]

> So it is more a recommended than a required thing?

One of the big priorities of systemd is to make early boot reliable and fully featured. You shouldn't need to wait until late in the boot process to be able to count on being able to connect to DBus, log messages, be started as services, and so on.

If we want PID >=2 to be able to utilize all of these features, then PID 1 basically has to provide (or launch) them all.

There's nothing stopping some process running as PID 236,421 from being the cgroup manager, but obviously no other programs are able to utilize cgroups until that manager is running.

That's not possible with Systemd because it's not just using cgroups in some cosmetic manner or just for your applications. Everything systemd does happens in cgroups.

> I.e. anyone using a different init could just run systemd early on? Wouldn't that make the whole "depends on an init system" discussion moot?

I don't completely understand what you're asking/proposing, but no, that doesn't sound possible and doesn't alleviate all of the "concern." Systemd's cgroup manager cannot be separated out like Canonical did when they forked systemd-logind.

There has been talk about making at least one other cgroup manager (by Canonical if I'm not mistaken). It would be highly beneficial to everyone if they copied the DBus API that systemd uses. Unfortunately, the people who oppose systemd would make it incompatible just for spite.

I suppose that doesn't provide much clarity on the larger question of dependency, but there is something important in that last paragraph. I think that the best feature -- bar none -- of systemd is its extensive use of DBus for all of its public API (and most internal, too). When people say that Gnome or whatever depends on systemd, that's only incidentally correct. They depend on something implementing a DBus API, which systemd defined, stabilized, and published first.

There's more than one way to skin a cat, and I don't see any reason why there can't be multiple implementations of these DBus APIs if some groups insist on alternative choices for their own sake.

In regards to the coupling question (which I think is asinine tbh), I think the better question is whether a package can have a mandatory dependency on DBus and *some* provider for a freedesktop.org DBus API specification. I don't see how anyone could argue with that in a meaningful way.

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 18:28 UTC (Thu) by krake (subscriber, #55996) [Link]

> One of the big priorities of systemd is to make early boot reliable and fully featured.

Sure, but that wouldn't apply for anyone running a different init, for whatever reason.
Independent of whether they don't need that or solve that by other means doesn't invalidate systemd's purpose as a, well, system daemon.

> I don't completely understand what you're asking/proposing, but no, that doesn't sound possible and doesn't alleviate all of the "concern." Systemd's cgroup manager cannot be separated out like Canonical did when they forked systemd-logind.

My question wasn't about somehow separating out cgroups or anything, more the opposite.

The very helpful answers so far seem to say that there is no kernel-side restrictions on which process can access those features.

That, if true, implies that systemd can access them independent of its process ID.

If it is run as init, it is in charge of the booting, with all the nice effects you've described.

If it is not running as init, it should still be able to manage cgroups, kdbus, etc., no?

So while running systemd as init would render the best possible integration, running it as the main system daemon would still satisfy e.g. logind's requirements, right?

So even if systemd were the only implementation of the interfaces used by logind, it would not imply a dependency on any init.

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 19:27 UTC (Thu) by fandingo (subscriber, #67019) [Link]

> So while running systemd as init would render the best possible integration, running it as the main system daemon would still satisfy e.g. logind's requirements, right?

I think that we're on different wavelengths as to what logind actually does. Logind isn't anything more than a DBus API specification (availabe at http://www.freedesktop.org/wiki/Software/systemd/logind/ and definitely worth scanning over briefly) and an implementation of those APIs.

There are a number of ways that the implementation can work. (I'd argue that the best is what systemd does.) The systemd-logind implementation does use cgroups, but that's rather incidental to the whole thing. Gnome doesn't know nor care whether cgroups or something else is used. Without delving too deep into the analysis, it's reasonable to believe that using the kernel namespace feature could form the basis of another logind implementation.

To your particular question, that is correct, although you don't need that much of the full systemd actually running. The systemd-logind that Canonical forked (v204 or something) uses the traditional cgroup fs controls and works fine largely outside of the rest of systemd.

What's interesting is how this continues to work for Upstart/Ubuntu. The new cgroup API has already been released (and systemd supports it). The cgroup fs API isn't immediately going away, but it will at some point. That's where the interesting part comes in. There's three approaches to take:

1) Implement a cgroup interface that simply provides the existing cgroup fs API (or just as much as logind needs), and continue to use the forked systemd-logind. This is likely the simplest approach if only because a fs interface is more simplistic and wouldn't require as many features.

2) Try to use the upstream systemd-login and implement a cgroup manager that follows the systemd DBus cgroup API. If anyone does this, he'll probably cut off his nose to spite his face, too. So much work to arrive at the same destination.

3) Use systemd's cgroup manager and logind. This isn't practical: Lennart has specifically stated that the cgroup manager will be tightly integrated with systemd. This option basically means using full-on systemd in all its glory. Even if possible at first, this sets into motion a transition to full systemd.

The problem is clear: a cgroup manager will be required in the not too distant future. That will require users of forked logind (or re-implementations of the API) to figure out some solution that's likely to be labor intensive.

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 19:38 UTC (Thu) by krake (subscriber, #55996) [Link]

Right.

I get the part about the interfaces and them being implemented in other ways, Some people seem to think this is not a viable option while others think it is.

What I am wondering about is why using the existing implementation, i.e. systemd-logind + systemd, seems to imply systemd as init?

As far as I can tell from all answers is that systemd doesn't have to be init to talk to the necessary kernel parts.

Highly recommended perhaps, but not required.

Therefore even a dependency on the systemd implementation of said interfaces does not imply a dependency on systemd as init, which, as I wrote before, would render the whole discussion about loose or tight dependency moot. There simply is none.

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 19:59 UTC (Thu) by fandingo (subscriber, #67019) [Link]

> I get the part about the interfaces and them being implemented in other ways, Some people seem to think this is not a viable option while others think it is.

Honestly, I don't get the feeling that many people, including some on the Debian technical committee, even understand the issue at all, care to understand, or may be intentionally misleading others.

This is -- what -- the third argument that really grasps at straws, and I would argue the most pernicious. It's exactly the sort of thing that is confusing to people without software development experience or those who haven't taken the time (with the proper attitude) to learn how systemd works.

Debian's technical committee starts another init system vote

Posted Feb 7, 2014 13:48 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

I don't think systemd would work as non-PID1. The rules for signals are completely different (it hangs rather than exiting on pretty much any signal). If it gets killed in a non-PID1 role, how does it assume the cgroup manager role? Even so, the data structures and bookkeeping it was doing is lost. Actually, that's a good question for non-systemd cgroup managers.

Debian's technical committee starts another init system vote

Posted Feb 7, 2014 14:03 UTC (Fri) by krake (subscriber, #55996) [Link]

if it gets killed as PID 1, doesn't it also lose the bookkeeping information?

Or does the kernel prevent PID 1 from being killed?

Debian's technical committee starts another init system vote

Posted Feb 7, 2014 14:07 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

If PID1 dies, the kernel panics. The rules for signals in PID 1 are different. By default, all are *ignored* there. To catch a signal, a handler must be set up. What systemd does for normally-deadly signals (SEGV, INT, PIPE, etc.) is try to recover and, failing that, enter a busy loop so the kernel is still available.

Debian's technical committee starts another init system vote

Posted Feb 7, 2014 14:14 UTC (Fri) by krake (subscriber, #55996) [Link]

Well so in either case one would reboot or at least go to a very basic system.

So I'd say the expected case is systemd not dying.

Debian's technical committee starts another init system vote

Posted Feb 7, 2014 14:19 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

I'd agree the expected case is not dying, but not being PID1 devoids you of guarantees you could otherwise make (e.g., even root can't kill me because I ignore SIGKILL). If the cgroup manager isn't PID1, you have to figure out how to deal with it disappearing in all the apps that talk to it.

Debian's technical committee starts another init system vote

Posted Feb 7, 2014 14:29 UTC (Fri) by krake (subscriber, #55996) [Link]

Sure, but that is something the init system would then have to take care about.

If its cgroup manager died, independent of whether it is systemd or something else, then it has to deal with that in some way, e.g. suggest reboot, switch to runlevel 1, terminate everything else and restart the cgroups manager, whatever.

Debian's technical committee starts another init system vote

Posted Feb 8, 2014 1:01 UTC (Sat) by smurf (subscriber, #17840) [Link]

No, that's not "independent of whether it is systemd or something else". Quite the contrary. If it's systemd, then the cgroups manager _is_ PID 1. Hence it cannot die (at least not easily).

Anyway, that's not a common problem. The real problem is that if the cgroups manager is external to PID 1, you get interesting concurrency issues and, more likely than not, fun-to-debug race conditions which simply do not exist with systemd.

In any case, nobody has yet offered any technical argument why this kind of separation should be desireable, much less necessary.

Debian's technical committee starts another init system vote

Posted Feb 8, 2014 10:25 UTC (Sat) by krake (subscriber, #55996) [Link]

> If it's systemd, then the cgroups manager _is_ PID 1.

So far the comments I've seen seemed to indicate that systemd can be run as the central system daemon even if it is not PID 1.
Does systemd disable its cgroups capabilties when it detects it is not running as PID 1?

> Hence it cannot die (at least not easily).

How is the PID related to how easily a process can die?
PID 1 won't prevent it from crashing, so is there some kernel protection of PID 1 that removes other reasons for dying?

> In any case, nobody has yet offered any technical argument why this kind of separation should be desireable, much less necessary.

I don't think anyone is arguing about this being necessary, I was just trying to understand why depending on systemd would imply depending on systemd as init.

So far I've determined that this is highly recommended but not, e.g. enforced by kernel policy.

It can of course very well be that systemd crashes horribly when it detects it is being run with PID > 1, but nothing I've read so far seems to indicate that.

Debian's technical committee starts another init system vote

Posted Feb 8, 2014 10:48 UTC (Sat) by palmer_eldritch (guest, #95160) [Link]

> So far the comments I've seen seemed to indicate that systemd can be run as the central system daemon even if it is not PID 1.

It can't, even if it could, it wouldn't be supported by systemd developers.

> How is the PID related to how easily a process can die?
> PID 1 won't prevent it from crashing, so is there some kernel protection of PID 1 that removes other reasons for dying?

PID 1 can't be killed. Of course, if it crashes it dies and the kernel panics.

> why depending on systemd would imply depending on systemd as init

Because systemd is an init system, any other use for it isn't supported by its developers. Some components might happen to work without systemd as PID 1 but there's no promise they'll keep working. Systemd PID 1 is the core of systemd, wanting to use the services it provides to userspace without it is kind of like wanting to use a kernel module without the kernel.

Debian's technical committee starts another init system vote

Posted Feb 8, 2014 11:22 UTC (Sat) by mchapman (subscriber, #66589) [Link]

> It can't, even if it could, it wouldn't be supported by systemd developers.

There are --system and --user flags that override the auto-detection.

Regardless, starting systemd in system mode as something other than PID 1 has only limited support. The documentation says: "In practice, passing --system explicitly is only useful in conjunction with --test."

Debian's technical committee starts another init system vote

Posted Feb 8, 2014 11:44 UTC (Sat) by palmer_eldritch (guest, #95160) [Link]

My bad, so there is an option to run systemd without it being PID 1.

It could be fun, upstart as init and systemd running as a daemon... it would probably mean having to fork systemd so it can be useful when not PID 1 though.
That would be a funny evolution of the current mess.
And not so far-fetched, since Canonical already does this for logind on Ubuntu they might consider doing it for other components in the future.

Debian's technical committee starts another init system vote

Posted Feb 8, 2014 12:55 UTC (Sat) by smurf (subscriber, #17840) [Link]

Yeah, but then you'd have two init systems running side by side. So what happens when a package ships startup files for upstart and systemd?

Frankly, I see zero utility in this idea. There's no technical advantage.

Debian's technical committee starts another init system vote

Posted Feb 8, 2014 11:01 UTC (Sat) by mchapman (subscriber, #66589) [Link]

> How is the PID related to how easily a process can die?
> PID 1 won't prevent it from crashing, so is there some kernel protection of PID 1 that removes other reasons for dying?

As far as I know, the only extra protection PID 1 gets is that unhandled user-generated signals -- even fatal signals -- are always ignored. It's not even possible to set up a signal handler for SIGKILL, so a SIGKILL from userspace will simply be ignored by PID 1.

Kernel-generated signals are a bit different. There are a few cases in which these must terminate the process -- e.g. a segfault, or a recursive segfault if you have a SIGSEGV handler installed. If PID 1 exits in any fashion, the kernel will panic.

Debian's technical committee starts another init system vote

Posted Feb 7, 2014 22:19 UTC (Fri) by smurf (subscriber, #17840) [Link]

>> What I am wondering about is why using the existing implementation, i.e. systemd-logind + systemd, seems to imply systemd as init?

systemd managing cgroups is tightly coupled to systemd being the (eventual) parent process of everything it starts, because the two need to be synchronized. This is trivial if systemd is pid 1. It is not at all trivial otherwise.

Debian's technical committee starts another init system vote

Posted Feb 7, 2014 2:35 UTC (Fri) by jspaleta (subscriber, #50639) [Link]

systemd has been designed to run as PID=1... sure I get that.

The question I have... strictly in the context of Debian's balloting options is this....

can a system a a minimal init as PID=1 (maybe minit, maybe the traditional sysvinit), have systemd started as PID!=1 and then that systemd instance manage some portion of the services on the system, obviously sacrificing systemd managing early boot and perhaps fstab file system mounting?

Such a system would meet the requirements of loose coupling ballot language as it would not strictly require systemd to be PID=1. Its not ideal, obviously, but we are talking about meeting the policy requirements of a nearly deadlocked _committee_ decision. No technical solution to meet such a policy decision is going to be great, because the policy decision isn't great. It's absurb... but we work around damage in the network as best we can. Right?

Such a scheme with systemd PID!=1 is a potential way forward for everyone disrupted by the loose coupling policy statement and specifically unblocks GNOME team in debian from continuing to work with upstart release cadence and development. And more to the point it throws out entirely any strategic political benefit that could be gained from blocking a systemd dependency from growing in GNOME and other projects. Just having that option out there as a technical solution could reduce the desire to support loose coupling over tight coupling (if the desire is born primarily for strategic gain and not technical reasoning, but I will not make that judgement as to specific motivations)

Basically it would create for systemd the same sort of situation that exists for runit now in the debian packaging. a Debian system can be modified to run as PID=1, replacing the default sysvinit. Or it can be started from sysvinit, and manage other services even though its not PID=1.

Yep.. runit exists...packaged in Debian...with instructions on how to use it as alternative init as PID=1.. and there is at least one addon package in the reposityr which explicitly requires runit to be running to function (a logging helper utility). And its been like that for a while. Systemd depedency in GNOME isn't really breaking new ground.. its just no longer a niche thing or a cornercase in the repository. But its not precedent setting... runit is precedent setting in the scope of Debian as far as I can tell. And well, there's also upstart and mountall (which seems to only work with upstart's event model) but let's not talk about that right now. I look forward to seeing the lose coupling options win so I can start a campaign to see mountall ejected from Debian repo because it only works with upstart as PID=1. What's good for the goose is good for the gander as they say.

The coming requirement that you can only run one cgroup manager, throws a wrinkle into this as clearly you can't run (the yet to be usable) cgmanager side-by-side with systemd in this sort of scheme, but Debian would have to choose to support the new API instead of the old cgroups API for that to matter... and that decision is tangential and quite frankly not even on the radar for Debian as as project yet. M implementations of cgmanger for any positive value of M>1 gives you the same problem as you have with the init system choice right now. You can only have one running on the system. Seems to me you might as well couple that problem and bless exactly _one_ cgroup manager for each init system you support and collapse the uniqueness problem back down. Because you sure as hell are not going to be able to adequately support the N*M space of init systems with cgroup managers once you have people experimenting with the minit equivalent of a cgroup manager. And its going to happen...eventually. So meh...

I think there's a way out of the tight bind that loose coupling presents on innovation and debian developer range of motion. You just have to allow Debian systems to sacrifice the benefit of systemd management of early boot but still let systemd manage a subset of services. runit packaging is constructed this way already.

-jef

Debian's technical committee starts another init system vote

Posted Feb 7, 2014 2:45 UTC (Fri) by mpr22 (subscriber, #60784) [Link]

A quick look at the man page tells me that systemd does not support being run in "system" mode unless it is PID 1, and my gut feeling (which might be wrong) is that Lennart probably doesn't want to maintain such a mode of operation.

Debian's technical committee starts another init system vote

Posted Feb 7, 2014 3:04 UTC (Fri) by jspaleta (subscriber, #50639) [Link]

I don't think upstream's support for this is..required. The Debian maintainers would need to assess how difficult it would be to maintain that capability as a downstream patchset (versus other options available).

Look, trying to adequately support the loose coupling mandate is absolutely not going to end up with a clean solution that can be upstreamed. No matter where the patches end up living in the stack, Debian is going to be holding on to distributor specific patches somewhere to make this work.

The question is, what's the least painful way to meet the requirements of bad policy decision? A potentially doubly absurd decision,if the decision ends up being systemd is the default for debian linux, but that you can't rely on what the default init system provides as enhancements over alternatives. yes that is still a possible outcome here thanks to the way the balloting is designed. Debian: bring you technically better solutions by default, you aren't allowed to rely on. The gods of irony are sated having gorged themselves on the bounty of tribute provided by this discussion and the voting. Technical committee...indeed.

This problem facing the committee right now (with the repeated aborted votes), and the potentially really grotesque outcome of not being able to make use of the technical benefits of the chosen default init...is the direct result of coupling the two issues together in one ballot and having the complexity of the ballot result in more confusion and difficult than is really necessary. It could be argued by some, that this is delibrately done to gain strategic advantage to block what would other wise be technically sound decision making on either issue. But it is what it is, and the committee is what it is.

Brace yourself... GR is coming.

-jef

Debian's technical committee starts another init system vote

Posted Feb 7, 2014 10:07 UTC (Fri) by fmuellner (subscriber, #70150) [Link]

The question is, what's the least painful way to meet the requirements of bad policy decision?

Assuming an outcome of systemd with loose coupling, the least painful approach for the GNOME maintainers would be to not do anything IMHO:

  • don't depend on systemd (as mandated by the committee)
  • consider all lost functionality tolerable degradation (as allowed by the committee)
  • expect users who change the init system to know what they are doing (either by installing an alternative logind implementation (if it exists), or by accepting the reduced functionality)

This is worse than depending on a virtual logind1 package which is considered tight coupling, but it would at least give the best option to users of the default init system.

Debian's technical committee starts another init system vote

Posted Feb 7, 2014 15:54 UTC (Fri) by dlang (subscriber, #313) [Link]

gracefully handling the case where some functionality that you would like to use isn't there is a good thing to do in any case.

Debian's technical committee starts another init system vote

Posted Feb 7, 2014 16:09 UTC (Fri) by fmuellner (subscriber, #70150) [Link]

Yes, in particular as it is possible to disable logind. Still, I don't think that graceful handling will mean to replicate the functionality by other means (ConsoleKit) indefinitely - eventually not having the corresponding functionality in the underlying OS will result in not having the functionality in the UI.

Debian's technical committee starts another init system vote

Posted Feb 7, 2014 16:27 UTC (Fri) by fandingo (subscriber, #67019) [Link]

The easiest way to deal with a bad policy decision is to gradually ignore it.

No matter the specific outcome of the decision, a logind interface providing init system will be chosen. There will also be another init system that supports a logind interface. For every other init system, they need to make improvements.

Debian's technical committee starts another init system vote

Posted Feb 7, 2014 18:09 UTC (Fri) by jspaleta (subscriber, #50639) [Link]

I think you missed my point. The policy reaches further than logind. If this were a specific policy to address logind on a case by case basis that would be entirely different. But the proponents of loose coupling are using an overly broad policy decision that will have impacts outside of logind.

Correct me if I'mn wrong. But mountall's event model only works right now with upstart as init correct? Under any existing interpretation of the loose coupling policy... mountall would have to be thrown out, until mountall works correctly with...systemd? I fully expect the upstart/mountall maintainers to ignore the fact they are out of compliance with the policy.

This is crazy, and having the technical committee set forth a policy their own membership will disregard in their work as DDs only undermines the authority of the CT membership. This hasn't been thought through and the policy is going to disrupt things and lead to a cascade of procedural actions instead of..collaboration.

What would be far more sane, would be to explicitly block the logind integration for a short period of time to give those interested in getting the alternative implementation spun up. Give them a hard deadline to meet, and prevent this issue from blocking the GNOME maintainership team from doing their work indefinitely. Does it suck to put a block up at all? Yes. But that's effectively where things stand right now..blocked. A well scoped, finite duration block for logind integration specifically is far less disruptive than an open ended policy statement that will screw with normal collaboration and technology integration among the maintainers across the archive.

The committee is overreaching on this policy issue and the proponents have not made any effort at all as far as I can tell to look outside of the logind issue and see how their policy impacts other crap right now....crap like mountall. Boneheaded, absolutely boneheaded. The best thing that could happen for everyone is if a ruling comes down that the TC doesn't have jurisdiction to deal with the loose/tight question and needs to refer it to the policy making body before taking it up. But its okay... a GR is coming regardless.

-jef

Debian's technical committee starts another init system vote

Posted Feb 7, 2014 18:22 UTC (Fri) by fandingo (subscriber, #67019) [Link]

> I think you missed my point. The policy reaches further than logind. If this were a specific policy to address logind on a case by case basis that would be entirely different. But the proponents of loose coupling are using an overly broad policy decision that will have impacts outside of logind.

Russ Allbery's email (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#5877) perfectly describes my opinion on coupling. I particular:

> > [...]it will end up like other similar Debian features that are required" but uninteresting to nearly everyone and therefore bitrot and are effectively non-functional.

> What would be far more sane, would be to explicitly block the logind integration for a short period of time to give those interested in getting the alternative implementation spun up.

Absolutely. Again, I defer to Russ since he says it better than I could:

> > It also doesn't distinguish between right now and after the jessie release, which I think is inappropriate. I think there's a huge difference between depending on an init system right now for the jessie release, which is something I think we should only do if there's really no technical alternative available at all, and depending on an init system or set of init systems after jessie, which I think is a reasonable way of handling the long-term migration path away from supporting sysvinit scripts.

I'm still trying to get through the emails from the past day, but I'm surprised and distraught -- like you -- that the TC seems to be going far beyond the issue that was presented to them. They are not supposed to take up issues on their own, and that seems exactly like what is happening with the coupling quibble. I would much like to see the vote split. If they want to decide coupling first, fine do that on its own. They need to decide on systemd, SysV, or Upstart first. Get rid of the GR and FD votes because those are really abdications or abstentions.

Debian's technical committee starts another init system vote

Posted Feb 7, 2014 20:54 UTC (Fri) by fmuellner (subscriber, #70150) [Link]

As insane as I think all the "loose coupling" stuff is, it has been drafted carefully enough to exempt cases like mountall - the whole point of mountall is to work around limitations in upstart, so considering it "part of an init system" isn't far fetched at all. Heck, I doubt anyone would try to ban gnome-logs for its journal dependency - all the latest charade appears to be about is blocking "big" software like GNOME until their own logind implementation catches up with systemd (which raises the question if it's really as close to completion as has been claimed) ...

Debian's technical committee starts another init system vote

Posted Feb 7, 2014 4:06 UTC (Fri) by fandingo (subscriber, #67019) [Link]

The systemd developers aren't interested in a limited mode. It makes their code cluttered and achieves a result that they consider undesirable. It's also going to lead to seriously broken configurations. I don't think the logind situation is a good exampel because that is re-implemented (or forked and maintained) by another group. I really wonder what happens when there's an alternative cgroup manager, and someone throws a fit that systemd cannot be used with a different cgroup manager.

I really hate the loose/tight coupling curve ball that Ian threw into this whole debate. The issue seems contrived and each position is nonsensical. Most importantly, this kind of issue shouldn't be holding up the main question. If lack of multi-init support actually becomes a real problem (There isn't much indication that it has been so far.), then it can be dealt with at that point. But whatever, the argument needs to be met, so let's dive in.

I think systemd owes a substantial amount of its quality and success to the stability and good design of its various public and private APIs. Applications largely receive information and make changes through a DBus API. There are also some C libraries and a few file formats. Of the 42 systemd components, 41 are considered guaranteed stable interfaces. The developers indicate that 29 of those components can be re-implemented independently, and honestly, I'd argue that a few more could be, and a couple simply don't need re-implementation as they refer to internal systemd state/configuration.

A project that has such well define, stable, and re-implementable interfaces automatically qualifies as loosely coupled. I think that it is only natural that a package be able to require that API X be supported. It would be a mistake for a developer to turn up his nose and refuse work with program Y even though it has a competent implementation of that API. That's why I think the Ian's position is nonsensical. In the particular example, anyone can implement the necessary features of logind that Gnome needs. Ubuntu already has such an implementation, even if it is just a fork of systemd-logind.

If the Gnome developers want to work on another init system, it is incorrect to patch Gnome software around that when the API is publicly implementation. The better solution would be to implement that API and submit packages to those upstreams (or the Debian maintainers).

This debate has turned into trying to either handicap programs that want to use advanced features or contort the advanced programs into being worse. That's madness when improving the features of the stragglers is the best option.

Honestly, I don't see the coupling requirements having any effect. SysV and OpenRC will be gone quickly. Upstart may stick around because Canonical owns all of the copyright, but I expect it to implement as many of the interfaces as applications need. In a few years, Upstart may support "all" of the systemd features, but I expect that the current design flaws are still around and probably more have crept in as well.

Systemd, and I mean the full thing, will be the only seriously considered init system on Debian in 3 years.

Debian's technical committee starts another init system vote

Posted Feb 7, 2014 13:03 UTC (Fri) by paulj (subscriber, #341) [Link]

What's the 1 unstable interface out of that 42?

Debian's technical committee starts another init system vote

Posted Feb 7, 2014 14:14 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

Last I looked, it was some udev interface. It may just not be considered stable yet and still in flux.

Debian's technical committee starts another init system vote

Posted Feb 7, 2014 16:30 UTC (Fri) by fandingo (subscriber, #67019) [Link]

My apologies, I meant to post the link: http://www.freedesktop.org/wiki/Software/systemd/Interfac....

The one item is "udev session switch ACL properties," which doesn't even have a link describing the feature. That leads me to believe that it is something under development.

Debian's technical committee starts another init system vote

Posted Feb 7, 2014 18:08 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

Sounds like an API for passing hardware file descriptors off to a display manager (say…X or Wayland?).

Debian's technical committee starts another init system vote

Posted Feb 9, 2014 0:57 UTC (Sun) by nix (subscriber, #2304) [Link]

Sounds more like an API for setting custom properties when sending the events that lead to adjustment of ACLs when the session is changed, to me. I don't know where you get hardware file descriptors from in that description.

Debian's technical committee starts another init system vote

Posted Feb 9, 2014 2:23 UTC (Sun) by mathstuf (subscriber, #69389) [Link]

Hrm. For some reason I read it as "protocol", not "properties".

Debian's technical committee starts another init system vote

Posted Feb 7, 2014 7:52 UTC (Fri) by dlang (subscriber, #313) [Link]

> If we want PID >=2 to be able to utilize all of these features, then PID 1 basically has to provide (or launch) them all.

anything launched in the system was launched by PID 1

people wouldn't be objecting if these pieces were separate and systemd could use them or alternative implementations, but the systemd developers have decided that all these pieces must be developed together and nothing else is to be supported.

That's where people start getting frustrated and upset.

Debian's technical committee starts another init system vote

Posted Feb 7, 2014 16:50 UTC (Fri) by fandingo (subscriber, #67019) [Link]

You're absolutely right. Let me be more specific.

Here's my current system:

USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.0 50316 6656 ? Ss Feb05 0:04 /usr/lib/systemd/systemd --switched-root --system --deserialize 23
root 2 0.0 0.0 0 0 ? S Feb05 0:00 [kthreadd]
root 3 0.0 0.0 0 0 ? S Feb05 0:01 [ksoftirqd/0]
root 5 0.0 0.0 0 0 ? S< Feb05 0:00 [kworker/0:0H]
root 7 0.0 0.0 0 0 ? S Feb05 0:00 [migration/0]

What I meant to say is that systemd could be PID 1, and then other systemd features would be implemented starting at PID 2. Everything that normally gets started at 2 would move down to 10 or whatever.

I don't see much practical difference between having the majority of the functionality in one process. The functionality that you advocate moving into different PIDs isn't that big anyway. For example, it's not like the whole of systemd runs in one PID.

Here's a crude search on my system:

~$ ps aux | grep systemd
root 1 0.0 0.0 50316 6656 ? Ss Feb05 0:04 /usr/lib/systemd/systemd --switched-root --system --deserialize 23
root 517 0.0 0.6 294276 109580 ? Ss Feb05 1:36 /usr/lib/systemd/systemd-journald
root 548 0.0 0.0 45276 4704 ? Ss Feb05 0:00 /usr/lib/systemd/systemd-udevd
root 693 0.0 0.0 34956 1804 ? Ss Feb05 0:00 /usr/lib/systemd/systemd-logind

Lastly, the systemd authors are against using alternative components, but that certainly shouldn't stop anyone from doing it on her own. All of the interfaces are stable, and it's easy to compile systemd to exclude pieces. Sure that's not as easy as, say, installing systemd and mylogind packages with everything playing nice. There's some real development work that would need to be done, and lots of packaging to finely split up the systemd functionality into lots of packages.

The problem that I have with many of the people complaining is that they don't want to do any of the work to make it possible. If it's not like ordering at a restaurant to pick out your systemd stack providers, they don't want to do it. Has anyone ever attempted a re-implementation of a systemd component and published the results?

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 15:33 UTC (Thu) by vonbrand (guest, #4458) [Link]

"Just ignore subtle bugs," yeah! Way to go!

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 16:30 UTC (Thu) by raven667 (subscriber, #5198) [Link]

Sometimes you just cron a reboot and walk away 8-)

Debian's technical committee starts another init system vote

Posted Feb 5, 2014 23:52 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

And the vote is canceled AGAIN because of a procedural issue and because some upstart developers want to drag it a little bit longer.

Dysfunction at its best.

I'm switching all my servers to RHEL/CentOS 7 once it's out. I'm sick of Debian.

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 3:25 UTC (Thu) by h2 (guest, #27965) [Link]

Exactly right, it's obvious that canonical won't let go of their dwindling upstart dream, even though nobody is using it except I believe chromeos, and that is almost certainly going to switch to systemd as well. Why ubuntu is doing this ridiculous behavior is beyond me, it's not a debian problem, it's an ubuntu issue, because if debian goes with systemd dependencies and init system, then ubuntu can't take the debian packages as is and use them.

I wouldn't blame debian in this, I would blame ubuntu, that's what all my reading shows me, the real arguments, and my own experience, show no advantage to upstart, and show that systemd is a pretty well thought out replacement, one that fixes many issues I've seen in my own experience supporting some many thousands of debian users over the years.

What's really sad is that 10 to 1 canonical will just decide to dump upstart for systemd in the near future anyway, like they do with all the projects they get bored with, or don't want to give resources to support anymore, and because their server customers are going to demand the increasingly default systemd in their server systems. Which makes this look more and more just like petulant Mark S not wanting to give up his toy, not an engineering discussion.

Debian is in a tough place, when some of your core devs work for canonical, they have a blatant conflict of interest and seem unable to overcome it. That's an unusual situation in gnu/linux distributions, usually it's the commercial entity, like SUSE or Redhat that controls what happens in the open version of the distro, but in this case, the problem is that the commercial version, ubuntu, depends on a certain system to be in place I think in debian proper.

Just by the way, when I started experimenting with systemd support, I was somewhat amazed to not hate it, and to find it pretty well thought out, ,which is more than I can say for what's I've had to deal with using upstart, which just looks like a bunch of hacks to my eyes.

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 11:22 UTC (Thu) by sionescu (subscriber, #59410) [Link]

You can switch to openSUSE right now, and possibly upgrade to SLES 12 later this year.

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 18:30 UTC (Thu) by nix (subscriber, #2304) [Link]

Because no other distributions have politics! Yes, they're all perfect flawless politics-free environments!

(It's not as if this politics is negatively impacting anyone, anyway. So Debian is arguing endlessly over a default. What's new? That's been going on for as long as Debian has existed. I fully expect to find that in 2100 Debian will be arguing over some default.)

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 18:50 UTC (Thu) by palmer_eldritch (guest, #95160) [Link]

> I fully expect to find that in 2100 Debian will be arguing over some default.
Yeah, they'll probably be arguing about whether or not they should replace sysvinit with something else...

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 23:17 UTC (Thu) by ovitters (subscriber, #27950) [Link]

> (It's not as if this politics is negatively impacting anyone,

I thought I made it really clear that it is impacting GNOME release management. Further, the Debian gnome package maintainers are impacted. We try to discuss, yet are only told we're "forcing things" and discussions are impossible because of the endless politics.

I'd rather have distributions who choose (themselves) to go another way to put some effort behind it. You want something? Then contribute back!

For your other assumption:
> Because no other distributions have politics!
"They do it too" is not a reasonable argument to make. And Mageia is pretty much politic free. Aside from that, even if everyone has politics, it doesn't make that acceptable.

Debian's technical committee starts another init system vote

Posted Feb 7, 2014 3:27 UTC (Fri) by rodgerd (guest, #58896) [Link]

It's unfortunate (or, I guess if you're a systemd refusenik/upstart proponent, very fortunate) that so much of the dependency discussion seems to have been centred around GNOME. GNOME, being seen as a "Red Hat project", and having a rough ride popularity wise in 3, is a polarising DE, so it seems like a lot of people hear "GNOME will not work well on Debian if tight coupling is not allowed" and say "Good riddance, fuck GNOME".

What they don't seem to understand - not least because Ian et al have kept their focus solidly on attacking GNOME - is that most of the common DEs are moving to an increased dependence on logind (and, by extension systemd). It's all very well for people who didn't want GNOME anyway to rally behind Ian's "Fuck GNOME, get them out of the archive" mails, but will they feel the same way when they lose KDE? How will they feel if the mooted ban on tight coupling bans Unity from Debian, since the 14.x release are likely to introduce hard dependencies on upstart?

Once systemd is bedded in everywhere except Canonical and possibly Debian, more and more software will assume "Linux = systemd" and build their toolchains appropriately. Canonical and (possibly) Debian will end up having to do a lot of work, or lose a lot of the package repo they're proud of.

Debian's technical committee starts another init system vote

Posted Feb 7, 2014 12:38 UTC (Fri) by ebassi (subscriber, #54855) [Link]

It's not as if this politics is negatively impacting anyone, anyway.

it actually is: the GNOME packaging team in Debian is not going to put more work in maintaining GNOME there if everything is blocked by a vote that could still largely sway on either side. the uncertainty, the endless bickering, and the delays are also powerful demotivating factors in a volunteer-driven environment.

this also applies to all the other environments that are switching, or considering to switch to systemd, like KDE and XFCE; if they can't rely on systemd for their own features, and if the hard-liners rider passes (no dependency on init system features) then Debian gets itself in a position where KDE, XFCE, and GNOME are not going to be in the repositories. what are they going to install by default? fvwm2 and a prayer?

Debian's technical committee starts another init system vote

Posted Feb 7, 2014 13:34 UTC (Fri) by jubal (subscriber, #67202) [Link]

Are you speaking for the Debian GNOME maintainer team? Is this an ultimatum?

Debian's technical committee starts another init system vote

Posted Feb 7, 2014 14:12 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

Not answering for the ultimatum, but if I were a maintainer for KDE, GNOME, or XFCE in Debian, the no-dependency clause is basically consigning me to significant amounts of work upstream probably doesn't care about and therefore its future maintenance. And these are changes that may not be easy to rip out, let alone reimplement with…whatever alternative *is* acceptable. If you're strapped for time already, moving the packages to another repo without the policy may just be the most beneficial path.

Debian's technical committee starts another init system vote

Posted Feb 8, 2014 0:52 UTC (Sat) by smurf (subscriber, #17840) [Link]

If I were a maintainer of such a package, I would simply ignore any mandate to not depend on a specific package just because that package happens to be one of three providers of /sbin/init.

I would accept patches by people who want to run Gnome/KDE/whatever under Upstart/OpenRC/whatever, but I would not accept any obligation to do that work myself.

This principle works very well for Debian-on-nonLinux-kernels. I see no reason whatsoever why it should not also work for Debian-on-nonSystemD-/sbin/init.

Debian's technical committee starts another init system vote

Posted Feb 7, 2014 16:15 UTC (Fri) by fmuellner (subscriber, #70150) [Link]

Well, the latest take seems to be: "it is OK to depend on logind, provided that there is at least one additional implementation"[0]

Which has this nice smell of taking other people's packages hostage to help your software to catch up ...

[0] https://lists.debian.org/debian-ctte/2014/02/msg00207.html

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 0:00 UTC (Thu) by jordi (subscriber, #14325) [Link]

corbet, you need to start thinking about new headlines for the topic.

https://lists.debian.org/debian-ctte/2014/02/msg00124.html

I seriously can't believe this.

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 0:43 UTC (Thu) by shmerl (guest, #65921) [Link]

Is Debian breaking the track record with this, or it's BAU to have such endless debates?

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 3:48 UTC (Thu) by plugwash (subscriber, #29694) [Link]

Debian seems to have difficulty making big changes in general but this one seems worse than any i've personally seen before. Multiarch also took ages but seemed to be more a case of one person obstructing progress whereas in this case there seems to be a deep divide in the project.

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 7:59 UTC (Thu) by josh (subscriber, #17465) [Link]

> Debian seems to have difficulty making big changes in general

I'd say "decisions", not "big changes". Big but uncontroversial changes are something Debian does extremely well.

> but this one seems worse than any i've personally seen before.

Agreed, but:

> whereas in this case there seems to be a deep divide in the project.

There's a deep divide in the technical committee; I wouldn't infer anything about the project beyond that. The TC attracts many strong and highly opinionated personalities, and in this case it happens to have several members with strong political biases towards upstart. It also contains a mostly overlapping set of members who seem fundamentally opposed to http://islinuxaboutchoice.com/ in favor of a nice-sounding but fundamentally broken philosophy of attempting to be all things to all users.

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 13:10 UTC (Thu) by HelloWorld (guest, #56129) [Link]

> It also contains a mostly overlapping set of members who seem fundamentally opposed to http://islinuxaboutchoice.com/ in favor of a nice-sounding but fundamentally broken philosophy of attempting to be all things to all users.
In fact, Ian Jackson even stated this explicitly.
https://lists.debian.org/debian-ctte/2014/01/msg00259.html

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 18:33 UTC (Thu) by nix (subscriber, #2304) [Link]

He's not the only person who thinks that, either. This anti-competition "every component should have only one alternative and it must have a dictator" attitude just rubs me up the wrong way. Why are so many systemd proponents objecting so hard to any competing init system being allowed to be installable?

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 18:44 UTC (Thu) by rodgerd (guest, #58896) [Link]

Ian objects to anything depending on systemd because he wants to avoid people chosing to depend on it. He's hardly pro-choice - in fact, he's rabidly opposed to letting either the users or the DDs make choices, since he's afraid they'll hake choices he doesn't like.

Much like so many of these arguments, this position is disinegious bullshit.

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 18:45 UTC (Thu) by josh (subscriber, #17465) [Link]

"Linux is not about choice" does not say that every component must have only one alternative. The issue is every single piece of software and Linux distribution should not have to support working with every underlying component. In the case of systemd, blindly advocating "choice" in init systems prevents any higher-level component from actually relying on systemd functionality.

Choice still makes sense, just not at the component-by-component level within a Linux distribution. Some Linux distributions can try upstart, and some can try systemd; users can try both and see how they like the ecosystem both enable. However, a distribution forced to support *both* can't properly integrate with *either*, and that's a large part of what makes good integration a challenge on Linux.

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 20:14 UTC (Thu) by HelloWorld (guest, #56129) [Link]

> Why are so many systemd proponents objecting so hard to any competing init system being allowed to be installable?
There is effectively no competing init system. Sysvinit is a pile of garbage held together by tons of shell^H duct tape, and OpenRC boils down to putting lipstick onto that pig. And then we have Upstart, the design of which makes hacks like mountall necessary and which suffers from bugs that can't be fixed except by effectively rewriting it. Not to mention that it lacks most of the features that systemd offers. Lennart Poettering had this to say about Upstart:
> 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.
https://plus.google.com/+LennartPoetteringTheOneAndOnly/p...
And I think he's spot-on.

Otoh, there's a lot of reasons not to support multiple init systems. Configuration files must be maintained, interoperability patches must be written, QA gets much harder, it must all be documented, things get more complex and thus less reliable and it leads to bugs not being fixed because people avoid them by switching to another init system. Oh, and of course upstreams need to worry about this whole mess as well instead of working on stuff that *users actually care about*, and companies need to train their administrators to deal with all this crap, wasting tons of time and money. Note that most of these points cause damage even if all init systems end up working perfectly fine (which isn't going to happen).

Now, if one day some *actual* competition shows up, or if somebody comes up with some hard evidence that the systemd design is flawed in some fundamental way that can't be easily fixed, then it's probably time to rethink the whole thing. But neither has happened as of yet, therefore choosing and/or supporting anything other than systemd is simply the wrong thing to do. Except maybe for some limited sysvinit support to allow for a smooth transition.

Debian's technical committee starts another init system vote

Posted Feb 9, 2014 0:51 UTC (Sun) by nix (subscriber, #2304) [Link]

There is effectively no competing init system.
That's absolute rubbish. I've been using something for the last sixteen years, and it still works. It might not be as nice as systemd, but it's still a competing init system.

What you mean is, there is no competing init system that you happen to like.

Debian's technical committee starts another init system vote

Posted Feb 9, 2014 2:28 UTC (Sun) by HelloWorld (guest, #56129) [Link]

> That's absolute rubbish. I've been using something for the last sixteen years, and it still works. It might not be as nice as systemd, but it's still a competing init system.
It's called legacy, not competition.

Debian's technical committee starts another init system vote

Posted Feb 9, 2014 13:55 UTC (Sun) by smurf (subscriber, #17840) [Link]

There's no init system with a feature set comparable to systemd's.

And yes, some people definitely like those features. A lot.

Debian's technical committee starts another init system vote

Posted Feb 10, 2014 0:04 UTC (Mon) by hummassa (subscriber, #307) [Link]

Come on. You are comparing a car (systemd) to a motorcycle (sysvinit). In London/Seattle/Belém (pick your own rainy city).

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 9:08 UTC (Thu) by smurf (subscriber, #17840) [Link]

It's somewhat telling that according to popcon, systemd has 9…30 times the users of upstart, depending on whether you cound the systemd or systemd-sysv package (the latter replaces init, otherwise you need to boot with init=/sbin/systemd).

Kieth and Bdale seem not to have voted yet. I sincerely hope that they will do so in a way that ends the endless (and, by now, pointless) debate.

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 9:17 UTC (Thu) by ovitters (subscriber, #27950) [Link]

Are those numbers accurate? I thought some stuff already pulls systemd packages in? E.g. GNOME wants a few init system agnostic daemons (timezone stuff, etc). But those daemons are part of systemd, so people might have ended up with those packages.

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 10:46 UTC (Thu) by hirnbrot (subscriber, #89469) [Link]

That depends.

gnome-settings-daemon (as per http://packages.debian.org/jessie/gnome-settings-daemon) requires the "systemd" package and I'm not aware of any other GNOME package requiring it (or systemd-sysv).

Now, does the systemd stuff GNOME needs actually require systemd to be PID1?

If not, then systemd-sysv would be the package that is only installed by people who actually want systemd-as-PID1 (as opposed to merely coping with it because GNOME needs it). It would be a lower bound though, because one could also choose the "init=/usr/lib/systemd/systemd" route to get systemd-as-PID1.

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 10:48 UTC (Thu) by kugel (subscriber, #70540) [Link]

According to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726763 yes. But there is probably a workaround possible, but someone needs to do it.

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 11:05 UTC (Thu) by hirnbrot (subscriber, #89469) [Link]

Well, that's not really a hard requirement, it's "degraded operation" (I, for example, wouldn't even have noticed it as I don't suspend and don't want to). This means it's still quite possible to run GNOME without systemd-as-PID1 with all core functionality intact.

Which leads me to believe that the number of people who install systemd-sysv purely to satisfy GNOME (but who would rather have another init system) isn't significant or at least much smaller than the number of people who want systemd and use it through "init=" (which is the recommended method) which means I personally believe in the number of systemd-sysv installations being a good lower bound on the number of debian users who actually want systemd to be the init system (or at least _their_ init system).

Debian's technical committee starts another init system vote

Posted Feb 7, 2014 7:23 UTC (Fri) by smurf (subscriber, #17840) [Link]

That's why I wrote "between 9 and 30*".

It's 9* if you look at systemd-sysv, which hard-replaces sysVinit.
I obviously have no idea how many people boot with init=/sbin/systemd.

Debian's technical committee starts another init system vote

Posted Feb 12, 2014 21:50 UTC (Wed) by micka (subscriber, #38720) [Link]

All systems where systemd was installed before systemd-sysv existed.
i wasn't aware of this package, and I'm sure sysv was still un-uninstallable (ouch!) when I switched everything.
So there are anything between 3 and the total number of debian installs :D

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 14:08 UTC (Thu) by cortana (subscriber, #24596) [Link]

popcon graph of systemd-sysv and upstart installations. I limited the date to the recent past, because for some reason the upstart installation number shot up to ~12,000 installations in July last year, before returning back to its former levels.

This graph actually underestimates the number of systemd users by some amount, since until recently the recommended way to try systemd was to install the systemd package, and reconfigure your boot loader to boot with init=/lib/systemd/systemd. The recent increase in systemd-sysv installations corresponds with the recommendation being changed to simply install the systemd-sysv package.

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 14:36 UTC (Thu) by vonbrand (guest, #4458) [Link]

So roughly 9 times more systemd. But around 50 vs some 450 is a wee bit less than all Debian installations... really can't conclude anything from this.

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 4:16 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

Oh, it gets better. They are planning an IRC discussion to write a new 'compromise' draft which, no doubt, would make sure that upstart is there for the next 10^29 years.

The soonest date this IRC session can be is Feb 10, after which another week or two will be spent on discussing fine distinctions between various options and procedural questions.

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 4:49 UTC (Thu) by Thue (subscriber, #14277) [Link]

Has anybody voted for "Further Discussion"? Not as far as I could see in a quick incomplete scan. So no real sign that the vote has been cancelled, only a (probably) unsuccessful attempt to cancel the vote.

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 4:52 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

Ian Jacskon and Steve Langasek did, at least.

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 5:21 UTC (Thu) by Thue (subscriber, #14277) [Link]

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 5:18 UTC (Thu) by hadrons123 (guest, #72126) [Link]

Even though Ian's proposal is not massively different fundamentally from Bdale's, all Ian wants to do is split the systemd supporters with the crappy idea of loose coupling and tight coupling which actually is not what a Debian user would want.

Does Ian propose that there is an option to use consolekit with systemd in Debian? I clearly don't see how it would work. Ian sitting in CTTE member should know better by this time. Unbelievable!

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 7:37 UTC (Thu) by Lionel_Debroux (subscriber, #30014) [Link]

As jspaleta described, in the comments of another news item about the same topic ( https://lwn.net/Articles/582585/ ), upstart is technically broken. By now, I'm convinced jspaleta is posting about the truth: not only he's basing his argumentation on facts, but also, if he were wrong, he'd have been rebutted in detail, in that news item and in another news item where the same content was re-linked by somebody else...

So - why is upstart a contender in the votes of a _technical_ committee, given its apparent technical debt and consequently, the manpower required to heal it ?
Counter-productive non-technical pressure from inside the committee by Canonical, perhaps ? Canonical could do better than stick to (seemingly) wrong technical choices at all costs and dragging upstream Debian down, which is not going to help the free software ecosystem...

Siduction is already using systemd and will not use upstart, other Debian derivatives will probably do the same even if Debian standardizes on upstart (sob).

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 9:19 UTC (Thu) by jspaleta (subscriber, #50639) [Link]

did someone say my name 3 times? Oh just once, well since I'm here...

The technical committee vote is basically not really that interesting at this point. It's clear there isn't a consensus forming in the committee, and now, and I say this with as much benefit of the doubt as I can muster, its just a series of procedural stalling actions to get the pointless wording of the failing options just exactly right. Or assuming bad faith, its a series of procedural stalling actions to get the wording of the options just right to game the voting system by over complicating the voting options. Either way there's no consensus that's going to show up and the decision, no matter what it is, is rife for review via a GR.

I'm already looking forward to the GR that is inevitable. I've got a bookie in Vegas prepping the odds for systemd upstart and initng right now for the GR. And really, a debate process where the developers of specific technology are not sitting in untenable conflict of interest situation will be good to see for everybody. I really don't like seeing technical leads dodge questions asked to address technical deficiencies in the design of the software with excuse that the answers won't change any of the voters minds. The GR debate will be a bit more honest a fight, where the technical deficiencies will be looked at in detail. It'll be bloody...but it will much more honest in its..brutality than the rhetorical fight going on in the technical committee discussion.

I'm also very interested in seeing a discussion where the Debian Hurd and BSD porters weigh in for themselves on available technology paths, instead of being spoken for by other vested interests. For example, I'd really love to here what the Hurd and BSD porters think about the nosh project as a path forward.

The Debian porters need to get intimately familiar with the options on the table. All of them. Systemd won't work for them, that's for sure, but nosh as a systemd unit file compatible alternative could. Upstart maybe portable but it is fundamentally broken, has been for years with absolutely no effort to finish the proposed rewrite. Its too late to save it, let it die a peaceful death. Debian does not have the manpower to save it. Even if Debian forks Upstart, I'd wager Canonical will lower its manpower committement to the codebase with the expectation that Debian will pick up the slack.

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 15:01 UTC (Thu) by HelloWorld (guest, #56129) [Link]

> For example, I'd really love to here what the Hurd and BSD porters think about the nosh project as a path forward.
What's the “nosh project”?

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 15:31 UTC (Thu) by khim (subscriber, #9252) [Link]

That one, I presume.

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 9:58 UTC (Thu) by tao (subscriber, #17563) [Link]

Canonical could do better than stick to (seemingly) wrong technical choices at all costs and dragging upstream Debian down, which is not going to help the free software ecosystem...
You're missing the detail that Canonical has control over Upstart (via the CLA) and can steer the direction of Upstart freely, while the direction of development of systemd is taking other interests into account too.

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 9:51 UTC (Thu) by kugel (subscriber, #70540) [Link]

Looks like the vote will be cancelled one more time. Bureaucracy dominates Debian's technical committee.

Debian's technical committee starts another init system vote

Posted Feb 6, 2014 10:24 UTC (Thu) by NAR (subscriber, #1313) [Link]

It seems that the series is renewed for the second season. I can't wait for our editor's writeup on the twists and turns in the next few episodes.

Yet another failure to make a decision

Posted Feb 6, 2014 17:08 UTC (Thu) by HelloWorld (guest, #56129) [Link]

Yet another failure to make a decision

Posted Feb 6, 2014 19:25 UTC (Thu) by dfsmith (guest, #20302) [Link]

You make it sound like FD is a bad thing.

I run my servers with sysV, my laptops with upstart, and my embedded systems with sysV (where the default systemd was broken for reasons I didn't have time to investigate).

The decision on default init is largely moot to someone like me who cares about getting work done. I'd support the option that causes *me* least downtime: currently FD.

Thank you to the committee for examining this so I don't have to! When there is a clear winner, I'm sure they'll move.

Yet another failure to make a decision

Posted Feb 7, 2014 1:59 UTC (Fri) by HelloWorld (guest, #56129) [Link]

> You make it sound like FD is a bad thing.
It is. It wastes a huge amount of time that should be used to fix the remaining integration bugs for systemd, and it damages debian's reputation. In fact, this farce leads users to believe that debian isn't something one wants to rely on in the future: https://lwn.net/Comments/584372/.

> When there is a clear winner, I'm sure they'll move.
That's the problem: they don't. Systemd is a clear technical winner. The technical committee isn't discussing technical issues, it's purely about politics and procedural issues at this point.

Yet another failure to make a decision

Posted Feb 7, 2014 3:05 UTC (Fri) by bronson (subscriber, #4806) [Link]

You realize, of course, that there will never be a clear winner?

Yet another failure to make a decision

Posted Feb 7, 2014 11:50 UTC (Fri) by HelloWorld (guest, #56129) [Link]

There is a clear technical winner: systemd. It's as easy as that.

Yet another failure to make a decision

Posted Feb 7, 2014 16:58 UTC (Fri) by oldtomas (guest, #72579) [Link]

Oh, come on, HelloWorld. We by now know your opinion, and we know that your opinion is valid for the whole world. Thanks.

Yet another failure to make a decision

Posted Feb 7, 2014 17:01 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

And why is he wrong? Systemd is clearly technically superior - it's a fact.

Upstart doesn't come close to the amount of features systemd offers right now, never mind sysv.

Yet another failure to make a decision

Posted Feb 7, 2014 18:46 UTC (Fri) by dashesy (guest, #74652) [Link]

I do not completely agree with this article, but seems relevant [1] about facts and opinions.
How ironic "OpenSource Tea Party" remark was made with accusation of taking progress hostage for political reasons, and now all of this!

1 - http://thefederalist.com/2014/01/17/the-death-of-expertise/

Yet another failure to make a decision

Posted Feb 8, 2014 10:48 UTC (Sat) by wertigon (guest, #42963) [Link]

SystemD does not work on Debian/HURD or Debian/KBSD. First SystemD would need to be ported to those two.

So, what is less work? SystemD porting - or Upstart fixing?

Yet another failure to make a decision

Posted Feb 8, 2014 11:12 UTC (Sat) by palmer_eldritch (guest, #95160) [Link]

Upstart doesn't work on Hurd and porting to FreeBSD isn't finished yet. So that would be Upstart fixing and porting vs. systemd porting. Also, once Upstart fixing is done, it's likely that it would depend on just as much on Linux-specific features as systemd.

And maybe, just maybe, the porters working on these two platforms should have their say into what should be done on these platforms rather than being used for specious arguments in political debates.

Yet another failure to make a decision

Posted Feb 8, 2014 12:51 UTC (Sat) by smurf (subscriber, #17840) [Link]

You can't port systemd. You can fork it. The re-implement all the Linux-specific features it uses. Good luck; you'll need it (and lots of time).

It'd be a hell of a lot less work, overall, to simply use OpenRC for the non-Linux ports. Which is what I'd expect the TC to decide – if it wasn't for the Canonical faction there.

Yet another failure to make a decision

Posted Feb 8, 2014 16:27 UTC (Sat) by anselm (subscriber, #2796) [Link]

Upstart would need to be fixed and then also be ported to FreeBSD and the Hurd. So the clear advantage of systemd here is that it isn't broken to begin with.

(Some people are purportedly working on a port of Upstart to FreeBSD, but that would be the broken version.)

Yet another failure to make a decision

Posted Feb 8, 2014 16:48 UTC (Sat) by fandingo (subscriber, #67019) [Link]

Who is going to do the work to port Upstart? Canonical seems to do practically all of the development, and they don't seem to ever do work outside their commercial interests. No one from Debian Hurd or kFreeBSD has spoken up offering to do the work.

Lastly, it looks like cgroups are coming to Upstart to fix some of the fundamental flaws.

Yet another failure to make a decision

Posted Feb 8, 2014 20:47 UTC (Sat) by smurf (subscriber, #17840) [Link]

Do you mean "a couple of years ago somebody posted in one of upstart's bugs on Launchpad that adding cgroup support would be a good idea"? or do you have more timely information?

Yet another failure to make a decision

Posted Feb 8, 2014 21:55 UTC (Sat) by fandingo (subscriber, #67019) [Link]

I'll start by saying that Upstart has abondiable documentation and public information.

Here's a video. They start talking about cgroups around 2:00. http://summit.ubuntu.com/uds-1311/meeting/21977/core-1311...

There's also a very, very brief roadmap https://wiki.ubuntu.com/Upstart/Ideas that mentions cgroups, but doesn't expand on anything.

I don't want to misrepresent them by saying that cgroups will be mandatory or used in an essential manner like in systemd. I merely think that cgroups make it really easy to reliably track processes, and the Upstart developers will find it convenient to utilize a Linux-only interface in the future. That's mostly due to my previous comment about how practically all of the Upstart devs work for Canonical, and they haven't done any real work to make Upstart portable.

Yet another failure to make a decision

Posted Feb 9, 2014 18:23 UTC (Sun) by smurf (subscriber, #17840) [Link]

Talk is cheap … code is what matters.
Anyway, even if they do start now: by the time they add that, and fix the event model, and fix their broken socket activation, it'll be 2015 and they still won't have the features systemd has now.

systemd also doesn't stand still: 40 commits by 10 people in systemd's git repo in the last week, compared to upstart's 5 commits by 1 person in the last month.

Yet another failure to make a decision

Posted Feb 9, 2014 18:26 UTC (Sun) by smurf (subscriber, #17840) [Link]

I retract the numbers of the latter statement; turns out that I only looked at the merges. Sorry about that.

It's still almost an order of magnitude less.

Yet another failure to make a decision

Posted Feb 7, 2014 23:05 UTC (Fri) by bronson (subscriber, #4806) [Link]

Oh I agree that on Linux, systemd is unarguably the technical winner.

But will it ever be a clear winner for Debian? Will anything?

Yet another failure to make a decision

Posted Feb 7, 2014 23:20 UTC (Fri) by vonbrand (guest, #4458) [Link]

Debian is 99+% Linux...

Yet another failure to make a decision

Posted Feb 10, 2014 19:29 UTC (Mon) by bronson (subscriber, #4806) [Link]

Oh I know! You need tell Ian Jackson and his Canonical buddies.

Yet another failure to make a decision

Posted Feb 7, 2014 23:29 UTC (Fri) by jspaleta (subscriber, #50639) [Link]

yes... systemd is already the clear winner among competing replacements for sysvinit in terms of adoption in another of ways.

compare popcon stats for runit, minit, upstart and systemd side by side.
compare _native_ configuration support for services for each of these as well as packaged in debian package collection right now.

Look, debian has had a history of _allowing_ alternative inits to be packaged, with no expectation at all that package maintainers try to do anything but provide for the default. Very few maintainers go through the trouble of providing pre-packaged runit configs or minit configs. These will continue to exist, and users will continue to use them (or not) based on local admin policy and factors with the knowledge that they will roll their own configs for the non-default init.

All Debian can attempt to do is make sure the upgrade path from one _default_ init to new _default_ init is done with as few regressions as possible and allow for a long tail of niche services to migrate from the old default initscript to the new native format over some longish timescale. And since all the candidate inits seems to support sysvinit parsing as a fallback for yet to migrated services...this isn't going to be a problem.

The ctte has too look at both sides of the ledger

Posted Feb 7, 2014 19:26 UTC (Fri) by mgb (guest, #3226) [Link]

Systemd is technically superior in some problem situations which most Debian Stable users have never encountered. In any stable and well-tested distro the advantages of systemd are mostly theoretical. But whatever systemd advantages there may be are only one side of the ledger.

Software developers have repeatedly had to deal with the fallout of systemd assimilating critical components and then forcing unnecessary changes. There is very real concern that the monster will continue to assimilate critical components. For example the systemd/GNOME love fest is already causing unnecessary work for other desktops.

We do not have the Cathedral's wealth. If we lose the Bazaar's flexibility our dream will die.

The ctte has too look at both sides of the ledger

Posted Feb 7, 2014 19:39 UTC (Fri) by fandingo (subscriber, #67019) [Link]

> Software developers have repeatedly had to deal with the fallout of systemd assimilating critical components and then forcing unnecessary changes. There is very real concern that the monster will continue to assimilate critical components. For example the systemd/GNOME love fest is already causing unnecessary work for other desktops.

I would be interested in reviewing any examples that you can provide. I'm genuinely unaware of any developers complaining of these effects. It seems to me that the Gnome and KDE developers have both made conscious decisions to use logind due to its benefits, and the fact that no one maintains ConsoleKit.

The ctte has too look at both sides of the ledger

Posted Feb 7, 2014 20:52 UTC (Fri) by niner (subscriber, #26151) [Link]

Mostly theoretical? Funny. I always thought that my work was practice, not theory. And at my work, systemd helped tremendously.

The ctte has too look at both sides of the ledger

Posted Feb 7, 2014 21:09 UTC (Fri) by pizza (subscriber, #46) [Link]

> In any stable and well-tested distro the advantages of systemd are mostly theoretical.

...Let us know when you find a "stable and well-tested distro". Next you'll be telling us that all software is bug free, hardware never fails, and unexpected input is never received.

Meanwhile, back in the real world, in which the majority of any given (well-written) piece of software deals with error handling, I can assure you that systemd's very-much-non-theoretical consistency and reliability results in a far more "stable" system than the still-theoretical one you espouse.

The ctte has too look at both sides of the ledger

Posted Feb 7, 2014 22:27 UTC (Fri) by ploxiln (subscriber, #58395) [Link]

I have similar sentiments, and I really like your explanation, thanks!

The ctte has too look at both sides of the ledger

Posted Feb 8, 2014 0:36 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

> Systemd is technically superior in some problem situations which most Debian Stable users have never encountered. In any stable and well-tested distro the advantages of systemd are mostly theoretical.
No, they are not. Debian's BIND script would still stall the reboot process if BIND fails to exit, for example.

And it's not a theoretical issue - it forced me to go to a datacenter at night, once. And there's a rich history of similar bugs. For example: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=173679

> But whatever systemd advantages there may be are only one side of the ledger.
Systemd has non-technical disadvantages - lack of portability to alien kernels and perceived hostility of its developers.

The ctte has too look at both sides of the ledger

Posted Feb 8, 2014 3:18 UTC (Sat) by mgb (guest, #3226) [Link]

Yup. There was a bug eleven years ago in Debian Unstable.

Our clients run 99.9% Debian Stable. We have better things to worry about than the extremely rare problems that systemd solves. (And which upstart also solves.)

Such as the pace of F/LOSS development being stalled a few years down the pike by the systemd monolith.

The ctte has too look at both sides of the ledger

Posted Feb 8, 2014 3:53 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

Rare? They ****ing aren't.

https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1... - we hit this bug. We had problems with NetworkManager hanging during restart, we had bugs with race condition (like local resolver racing with BIND server that handles the reverse domain name lookup) and so on.

These kinds of bugs just keep coming in non-trivial configurations. And I'm as hell don't want to tweak tons of shitty initscripts to make this mess work if there's a better solution.

The ctte has too look at both sides of the ledger

Posted Feb 8, 2014 4:18 UTC (Sat) by mchapman (subscriber, #66589) [Link]

> Rare? They ****ing aren't.

I can attest to that.

One of the most "interesting" Debian-initscript-related bugs I encountered was where I was managing nfs-kernel-server from Pacemaker (please don't ask why). Pacemaker would have certain signals blocked when it invoked the initscript. Of particular note, SIGINT was blocked. The set of blocked signals is inherited over fork, so it would propagate through the initscript to the knfsd task itself. On some kernel versions knfsd did not unblock the signals it handled. The end result was that the initscript was not able to subsequently stop the knfsd process; it would send the knfsd process a SIGINT and... nothing would happen. I had to change the initscript to use SIGKILL instead.

This kind of fault would simply not occur in the systemd model, since services are always launched in a consistent and sane environment.

The ctte has too look at both sides of the ledger

Posted Feb 8, 2014 6:47 UTC (Sat) by rodgerd (guest, #58896) [Link]

Clearly we should not solve today's problems lest we be trapped in a your dystopian fantasy.

The ctte has too look at both sides of the ledger

Posted Feb 8, 2014 8:00 UTC (Sat) by palmer_eldritch (guest, #95160) [Link]

> Such as the pace of F/LOSS development being stalled a few years down the pike by the systemd monolith.

Why would systemd stall F/LOSS development for years? Is that because people who can't live with it have to implement alternatives to the interfaces it provides?
Meanwhile, the rest of the world can go on and work on stuff they're interested in.

The ctte has too look at both sides of the ledger

Posted Feb 8, 2014 10:08 UTC (Sat) by cortana (subscriber, #24596) [Link]

If a job times out, systemd will eventually kill the entire bind.service cgroup, so I think you are safe even with init scripts.


Copyright © 2014, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds