| |||||||||||||
Myths not debunked but confirmedMyths not debunked but confirmedPosted Jan 27, 2013 21:10 UTC (Sun) by misc (subscriber, #73730)In reply to: Myths not debunked but confirmed by man_ls Parent article: Poettering: The Biggest Myths
Upstart is not bad, but not great. There is some design issues.
For one, the way it track process is by using ptrace. That's not a bad idea, but this doesn't work great for some kind of software. There is 2 bugs opened since 4 years about that ( https://bugs.launchpad.net/upstart/+bug/406397 and https://bugs.launchpad.net/upstart/+bug/703800 ).
Then upstart do not permit to have a daemon installed but not started. The state and the config file are conflated. See http://utcc.utoronto.ca/~cks/space/blog/linux/UpstartCoup... on the details.
On the same type of issue, there is this http://utcc.utoronto.ca/~cks/space/blog/linux/UpstartDepe... , ie, upstart config are just script, so that's the same problem.
The root cause is something solved by systemd, with the .include and the new directory system ( ie, using /etc/system/foo.unit.d/foo ).
Upstart config file are also harder to parse ( ie, this is a full blown DSL ), which doesn't help to create a tool to audit or modify them. While auditing is not something I ever seen, I know that some organisations requires this, so every roadblock that can be removed is better. And as someone involved into automated package checking, having a parsable format is better.
One last issue is the whole copyright assignation to Canonical, that AFAIK is always annoying since company exec tend to avoid letting people work on such projects ( and IMHO for good reasons ).
RHEL and Fedora did used Upstart for a time, Opensuse and Debian also looked at it at the same time. So if they collectively decided to not switch or to use something else, there is likely a technical reason.
(Log in to post comments)
Perhaps a myth after all Posted Jan 28, 2013 0:00 UTC (Mon) by man_ls (subscriber, #15091) [Link] Thanks for a very civil and informative answer. It makes me think that myth #9 is perhaps a myth after all.
Myths not debunked but confirmed Posted Jan 28, 2013 1:25 UTC (Mon) by mezcalero (subscriber, #45103) [Link]
To underline this, I think the sources of Upstart are really nice. It's very readable, well documented, has many tests. In many ways it's exemplary.
We didn't have any problems with the quality of code or anything. Heck, we have so much more bad code in our stack, Upstart totally stands out in quality. So, the implementation is fine, however the overall design was not, in our eyes, and that's very hard to fix without resulting in well, basically a pretty complete rewrite, and that's what we then did, after much consideration.
Myths not debunked but confirmed Posted Jan 28, 2013 10:23 UTC (Mon) by dmitrij.ledkov (subscriber, #63320) [Link]
In upstart, there is now support for /etc/init/foo.override file.
It's an overlay which can shadow any part of the job. E.g. echo "manual" >> /etc/init/foo.override will make sure that foo is never automatically started, only manually when a user does it explicitly.
For the NFS related dependency problem you outlined, sounds like you need a couple .overrides with modified "start on" conditions.
|
|||||||||||||