On 23 May 2013 10:37, Ole Laursen <o...@hardworking.dk> wrote: > Steve Langasek <vorlon <at> debian.org> writes: >> Sorry you ran into trouble with upstart. > > Not a DD, just a happy Debian user, hope you'll excuse me, but on the topic > of Upstart, I have some technical comments on why, surprisingly, I think it > may not be mature enough yet. > > A couple of years ago I was doing emergency consultancy work for a company > using Red Hat and upstart. The dev dude there was really on top of new tech > and had made Upstart scripts for starting his Python web apps (which I > thought was a great idea, this was back when Upstart looked like THE > alternative to sysvinit). > > However, when debugging it, we had some weird lock-ups from Upstart, > basically you'd ask Upstart for the status of the job and it would lock up > really hard (IIRC Ctrl-C wouldn't work). After much swearing, it wasn’t > immediately obvious why Upstart would be the culprit, I found this (at the > time) old bug: > > https://bugs.launchpad.net/upstart/+bug/406397 > > Upstart couldn't track the forks going on inside a started process reliably. > As one commenter notes: “I’m wondering why this bug has a importance of > “low”, as it renders using upstart for many daemons (including apache, > postfix and others) as impossible.” This bug doesn't appear to be fixed yet. > > So unfortunately, I don't think Upstart is ready for handling a server boot > with native job files. I had a look at the apache2 packages for Ubuntu > raring, and there’s a sysvinit file, but no Upstart job. > > I'm telling you the whole story here to explain that this isn't just a minor > problem for packages shipped with the distribution, it's also a potentially > big problem for ISVs. >
Yes, it's a real bug and as clearly stated in the bug report comments above it is due to using ptrace to count/track forks. The best way to run daemons under upstart is in foreground, then correct PID is tracked and the complete stdout/stderr is properly collected and stored in /var/log/upstart/$job.log (even early boot output). How to establish fork counts & the consequences of getting it wrong are well documented in the upstart cookbook (see below). As far as I understand (correct me if I am wrong), systemd instead of counting/tracking forks uses cgroups to keep track of the started processes. > > Also on technical merits although more philosophically, with Upstart you're > expressing yourself in an event-based DSL rather than writing configuration > files. It's pretty generic. But unfortunately, that means it's also not > entirely straightforward, and, I believe, easier to get wrong. Scott had > some explaining blog posts before he left Canonical that I still find > confusing (from the POV of just getting a job file done): > > http://netsplit.com/2010/12/20/events-are-like-methods/ > http://netsplit.com/2010/12/03/event-matching-in-upstart/ > Since those blog posts were published a coprehensive documentation book was written and is constantly kept up to date. http://upstart.ubuntu.com/cookbook/ It actually guides & explains upstart concepts in a coherent and straight-forward manner with a very large section of examples on how to achieve various goals & tasks. > Lennart Poettering wrote in his initial blog posts on systemd about why he > thought this fundamental model of Upstart wasn't entirely spot on, and while > I thought this might have been NIH BS at the time I've later come to the > conclusion that he's probably right. Taking as much confusing logic as > possible out of the job files does seem like a win. > Blog posts are interesting to read, but at times I'd like to look up reference manuals which are more than bear minimal man pages. Whilst systemd ships manpages, the website has either incorrectly formatted wiki-pages and/or eventual links to lennart's blog posts. Where is systemd's documentation? Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhluhbgvwkp8tsgicgmq2zermb61idbjgwd6261euohqn...@mail.gmail.com
