[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: using upstart in Debian [was, Re: Debian systemd survey]



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.


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/

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.


Ole


Reply to: