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

A call for votes in the Debian init system discussion

A call for votes in the Debian init system discussion

Posted Jan 26, 2014 12:44 UTC (Sun) by hadrons123 (guest, #72126)
Parent article: A call for votes in the Debian init system discussion

I think upstart camp has been playing the support(under constrcution) for non-linux kernels card for some time and I think Bdale put an end to that asking to decide on init only for 'linux', right now. I think its a clever move.


(Log in to post comments)

A call for votes in the Debian init system discussion

Posted Jan 26, 2014 18:11 UTC (Sun) by ovitters (subscriber, #27950) [Link]

Seems good to break it out in steps. First Linux only, then the others. Then analyse both outcomes and see how to make both happen at the same time as well as the implications.

I didn't really see any concrete advantages for going for Upstart on Linux in the discussion if you take everything into account. So, also taking into account that original author agrees it has some design flaws as well as the proven low bug fixing rate.

The portability is IMO going too quickly into "solution mode" (learned such stuff from project management ideas).

A call for votes in the Debian init system discussion

Posted Jan 26, 2014 20:16 UTC (Sun) by jspaleta (subscriber, #50639) [Link]

I dont see an advantage for upstart anywhere....

On the surface, the effort to port upstart to bsd looks like a good thing for bsd. But dig deeper, and you look at the 2+ year old, deep design, bugs against upstart, and you look at what Scott has communicated with regard to the rewrite necessary to fix those bugs by using more linux kernel specific mechanisms, like cgroups. And really I'm left wondering how on earth the currently upstart team can really consider porting upstart to any other kernel when the need for a significant rewrite of upstart is just hanging out there on the dev roadmap that Scott left behind, unaddressed and untended to.

Porting upstart, when those deep longstanding bugs are still open is asking for trouble. It's a trap!. If there's no game plan at all to address those bugs in a portable way, is it really in Debian-bsd's best interest to depend on upstart? For all the sincerity of the current upstream upstart maintainer team..they just don't have the manhours to get it all done on behalf of Ubuntu and all the Debian kernel flavors. They can't even get this deep stuff fixed for Ubuntu and its been a full 2 years for this stuff. So for any Debian kernel porting team to realistically consider relying on upstart as the default, they have to be prepared to dig in and help with the upstart development on some of these deep issues (like moving away from ptrace usage) And here again, I would be shocked if these porter groups found the manhours to contribute (even to a CLA-less Debian specific fork of the codebase)

And its not just "expect fork" and "expect daemon" syntax, which upstart proponents are now suggesting to remove entirely from Debian's fork of the codebase. No the problems are deeper than that. Though I do find it ironic that proponents are effectively suggesting that upstart native functionality be forbidden to be used by Debian developers, instead of _fixing_ upstart's expect logic to actually work as...expected. So that says a lot right there about the manpower and expertise available to address existing design problems in upstart running on linux, without even touching on whether the expertise and manpower are there to extend upstart further with more features or port it to different kernels. The people currently most knowledgable about how upstart internals, want to neuter upstart's "expect" logic to avoid problems. Great, just great.

-jef

A call for votes in the Debian init system discussion

Posted Jan 26, 2014 20:27 UTC (Sun) by AlexHudson (guest, #41828) [Link]

The multi-platform thing is such a red herring.

I was pretty interested in Hurd a number of years ago, because it was doing some interesting things that Linux still wasn't doing. Why would you want to copy the same init system as Linux? With the system of translators, for example, it's not clear to me that the ideal tool would look the same at all - in the same way the various tools that support them don't look like Linux tools.

It's useful to have the same / similar tools available under different kernels, but there has to be some difference otherwise it's just not worth having the different kernels. Linux is moving forward with a new init, the other platforms will do too, and they don't look much like systemd that's no bad thing.

A call for votes in the Debian init system discussion

Posted Jan 26, 2014 22:10 UTC (Sun) by tzafrir (subscriber, #11501) [Link]

What's wrong with depending on Upstart? It's much nicer than having them maintain a set of init.d scripts on their own.

In this case the Upstart (and OpenRC) people actually provide code. Nobody provides a port or partial reimplementation of systemd for those ports.

A call for votes in the Debian init system discussion

Posted Jan 26, 2014 22:31 UTC (Sun) by ovitters (subscriber, #27950) [Link]

It seems you're asking Jef to repeat to what he already wrote? Please first explain how his explanation was not good enough.

A call for votes in the Debian init system discussion

Posted Jan 27, 2014 0:16 UTC (Mon) by tzafrir (subscriber, #11501) [Link]

Here's an example:

> I do find it ironic that proponents are effectively suggesting that
> upstart native functionality be forbidden to be used by Debian developers,
> instead of _fixing_ upstart's expect logic to actually work as...expected.

(That's regarding "excpect fork" and such)

This functionality should not be needed in a properly-written service, as you should not write a daemon that forks. A forking daemon is likewise discouraged by systemd and will be likewise discouraged / forbidden by policy if systemd is chosen.

A call for votes in the Debian init system discussion

Posted Jan 27, 2014 0:31 UTC (Mon) by jspaleta (subscriber, #50639) [Link]

And yet... expect fork is used in existing upstart jobs out in the wild already...right? Ubuntu, as the gold standard for upstart integration hasn't disabled these upstart features yet right? Right?

It's one thing to draw a line in the sand and say debian isn't going to allow any forking daemons... going forward. They are allowed now under initscripts, right? So that's an interesting bit of backward compatibility drama the project is going to go through..convincing maintainers to change from forking to non-forking across the board.

But that doesn't say anything about whether upstart actually WORKS as designed. Your just paper over one problem with in upstart at best via a policy fight. It can still lose track of running services via problems parsing the embedded start/stop scriptlets that upstart jobs allow. Is deb going to also disallow those scriplets to workaround upstart's design flaws? Good luck with that.

A call for votes in the Debian init system discussion

Posted Jan 30, 2014 10:04 UTC (Thu) by hirnbrot (subscriber, #89469) [Link]

In a standard installation of Ubuntu 13.10 (in fact just the live cd under virtualbox), I'm counting 18 occurences of "expect " out of 96 files in /etc/init, with 6 of those being "expect daemon", and 12 "expect fork".

I'm also seeing 42 of what appear to be legacy init scripts in /etc/init.d, including a 364 line monstrosity to start udev (which includes mounting a tmpfs over /dev).

So: Yes, it's very much used in the wild, and if even Ubuntu hasn't fully converted to upstart in 7 years, I don't think there is any distribution that has.

A call for votes in the Debian init system discussion

Posted Jan 26, 2014 22:44 UTC (Sun) by johannbg (subscriber, #65743) [Link]

I dont understand why people seem to be so fixated on porting or supporting the init system in GNU/Linux on GNU/kFreeBSD and GNU/Hurd nor do I think people realize how much work would be involved trying to achieve that or they realize it and are trying to avoid having to do any of that work themselves on those ports.

To me it's dead given that GNU/kFreeBSD should be using openlaunchd [1] and GNU/Hurd should be using dmd both of which seem to be entirely left out of that huge thread ( the only thing Hurd init resembles init system in GNU/Linux is it's name more or less it's more of an bootstraping thing kinda ).

So basically the outcome if I was part of the Debian community and I had anything to say in the matter would be...

For GNU/Linux systemd is the choice
For GNU/kFreeBSD openlaunchd is choice
For GNU/Hurd dmd is the choice

With rest of the init system phased out and eventually dropped from the distribution and people focusing supporting only one for each and only these three init system as the way forward in Debian.

But hey that's just me by all means continue debating and wasting valuable migration and integration time of systemd for Jesse doing just that.

By my account of emails on that huge thread the entire service/daemons Debian ships could have been migrated to native systemd units four times already if the energy people have put into this debate would have been spent in doing just that instead.

1. https://github.com/rtyler/openlaunchd
2. https://gitorious.org/guix/dmd/source/a97a75a5fac10afe52e...

A call for votes in the Debian init system discussion

Posted Jan 27, 2014 0:07 UTC (Mon) by tzafrir (subscriber, #11501) [Link]

That is what you believe. However those two are not there. Systemd has been added to the current Debian Stable. It was added as a basically working but with rough edges. The current package works well. Upstart was added even before that and is more mature.

OpenRC should give you an idea of how long it takes to integrate an init system. It's still only in the experimental release, even though efforts to port it to Debian have started even before Wheezy was released.

So, if you think any of those two tools would work: just show us the code. A working Debian package. Please make sure it is ready in time. Jessie is frozen in Nov-5 and there's much integration work to be done before that.

A call for votes in the Debian init system discussion

Posted Jan 27, 2014 0:31 UTC (Mon) by jspaleta (subscriber, #50639) [Link]

I think its a misnomer to call upstart.. mature. That does a disservice to the concept of maturity. Upstart still misbehaves..badly..even in Ubuntu.
The problems with upstart are not distribution integration issues. The problems with upstart are deep, fundamental problems its design. These problems that have been identified and have gone unaddressed for years.
There are multiple open bug reports against it in launchpad where the active developer stated that a rewrite of Upstart would be needed to fix the bug. A rewrite that has never happened.

This is not maturity as I understand it, stagnation is not maturity.
The code has never reached maturity and is stuck in perpetual adolescence.

A call for votes in the Debian init system discussion

Posted Jan 27, 2014 1:37 UTC (Mon) by nirbheek (subscriber, #54111) [Link]

In the interests of documentation, and to make your own argument stronger, it would be nice to have a list of these bug reports and comments so that uninitiated people like me can follow along. Thanks!

A call for votes in the Debian init system discussion

Posted Jan 27, 2014 6:32 UTC (Mon) by jspaleta (subscriber, #50639) [Link]

As requested:

bug report indicated that conditional event parsing does not work as expected. Upstart lets you build event conditional statements like start on A and B or (C and D) but they do not work. Such constructions are considered valid syntax for job files...but they do not work as one would plainly expect them to.
https://bugs.launchpad.net/upstart/+bug/447654
Scott, as maintainer at the time, comments about "...event operator stuff being utterly broken..."

bug report indicating in embedded scriplets logic result in jobs not restarting when requested to.
https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/70...
Scott has a terse comment concerning lack of pre-stop coverage.

A pathelogical pre-stop bug report that Scott filed. This time upstart loses track of a running service entirely! That's a deal-breaker. This is as bad as the expect fork failure situation. Is Debian going to make it a policy to forbid all pre-stop scripts in Upstart job files to paper over this problem as well?
https://bugs.launchpad.net/upstart/+bug/539175
Scott makes a terse comment about needing to re-think the start/stop scripts and the event model.

bug report on event unblocking race condition
https://bugs.launchpad.net/upstart/+bug/516713
Scott, makes a terse comment with a sketch as to a solution to keep the events blocked, but clearly its never integrated.

bug report indicating upstart fails to unmount systems cleanly:
https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/10...
read more on this specific issue and how systemd handles this from Lennart's G+ account recently.

bug report indicating failure of expect fork.
https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/53...
and
https://bugs.launchpad.net/upstart/+bug/406397
Scott, as maintainer at the time, writes in a comments to both bugs about a pending rewrite to fix this. His proposed solution, to remove ptrace and to potentially use cgroups instead. He also speaks out against the introduction of pid file tracking as a fallback mechanism for job files to use as an alternative to expect fork pid tracking mechanism. Expect fork is still broken, upstart still does not allow pid tracking as a fallback.

So lets recap. the event handling is racey. The pre-stop scripts design is broken. The event conditional logic is broken, the start/stop command logic is racy/broken, the expect command is broken. What's left. Oh yeah... upstart's backwards compatibility for existing sysvinit scripts is good enough to rely on. But if you want to rely on anything upstart purports to bring to the table..get ready for dentist visit like fun time.

A call for votes in the Debian init system discussion

Posted Jan 27, 2014 6:46 UTC (Mon) by nirbheek (subscriber, #54111) [Link]

Awesome. Thanks for the detailed list, jspaleta!

A call for votes in the Debian init system discussion

Posted Jan 27, 2014 10:19 UTC (Mon) by misc (subscriber, #73730) [Link]

It is also worth to note that the latest cgroup integration proposal in upstart ( https://lists.ubuntu.com/archives/upstart-devel/2013-Nove... ) explicitely exclude cgroup to track processes.

I have also been pointed on this post, explaining that the portability of sysvinit is not really what people think it to be ( https://teythoon.cryptobitch.de/posts/on-portability-of-i... )

A call for votes in the Debian init system discussion

Posted Jan 27, 2014 11:07 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

Yup. Upstart's motto is: "We do things as differently as possible compared to systemd". Even if it makes new features next to useless - just look at socket activation.

A call for votes in the Debian init system discussion

Posted Jan 28, 2014 8:36 UTC (Tue) by geertj (guest, #4116) [Link]

Thanks! The most factual and therefore convincing argument so far in this discussion.

A call for votes in the Debian init system discussion

Posted Jan 27, 2014 8:10 UTC (Mon) by tzafrir (subscriber, #11501) [Link]

"Mature" here means that I install a package and get the software working. Besides the sore issue of sysvinit being essential, which means that installing upstart is a bit scary. If you want to include an upstart init file, you just use the standard Debian packaging tools, which do the right thing with them (an example of the wrong thing: with the current systemd in Wheezy, there is no simple way to properly enable a service in the postinst script. There are several methods you can do on your own, but they generally fail if your system is installed where systemd is not PID1, such as in a debootstrap. This was fixed already).

How do you install openlaunchd on Debian? How do you install mdm or whatever it is called? How do you package their configurations?

A call for votes in the Debian init system discussion

Posted Jan 27, 2014 8:45 UTC (Mon) by johannbg (subscriber, #65743) [Link]

With whatever method is used in Debian I presume and those maintaining those ports having to deal with the work involved in doing that.

And as far as I know Debian has never "officially" released any releases with either kfreebsd or hurd which makes it even less sense that they have anything to say which init system will be the default in Debian GNU/Linux part.

The kfreebsd and hurd communities in Debian have to decide for themselves which init system they want to use since in the end of the day they are responsible for implementing,packaging and maintaining it that work should not fall onto other maintainers hands.

A call for votes in the Debian init system discussion

Posted Jan 27, 2014 10:29 UTC (Mon) by tzafrir (subscriber, #11501) [Link]

https://www.debian.org/ports/ lists kfreebsd-amd64 and kfreebsd-i386 as official ports. hurd-i386 is indeed an unofficial port.

A call for votes in the Debian init system discussion

Posted Jan 27, 2014 16:26 UTC (Mon) by smurf (subscriber, #17840) [Link]

> Besides the sore issue of sysvinit being essential

This is no longer true. There is now a sysvinit-package which is indeed essential, but it is empty and pre-depends on sysvinit-core | upstart | systemd-sysv. Problem solved.


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