A call for votes in the Debian init system discussion
A call for votes in the Debian init system discussion
Posted Jan 27, 2014 6:32 UTC (Mon) by jspaleta (subscriber, #50639)In reply to: A call for votes in the Debian init system discussion by nirbheek
Parent article: A call for votes in the Debian init system discussion
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.
Posted Jan 27, 2014 6:46 UTC (Mon)
by nirbheek (subscriber, #54111)
[Link]
Posted Jan 27, 2014 10:19 UTC (Mon)
by misc (subscriber, #73730)
[Link] (1 responses)
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... )
Posted Jan 27, 2014 11:07 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Jan 28, 2014 8:36 UTC (Tue)
by geertj (guest, #4116)
[Link]
A call for votes in the Debian init system discussion
A call for votes in the Debian init system discussion
A call for votes in the Debian init system discussion
A call for votes in the Debian init system discussion
