[PATCH 5/5] activation: implement upstart activation

Lennart Poettering mzqohf at 0pointer.de
Thu Dec 23 23:37:00 PST 2010

On Thu, 23.12.10 23:07, Scott James Remnant (scott at netsplit.com) wrote:

> > But what happens if the service fails to start up? If you send no error
> > message back on failure, then actviation will time-out. You definitely
> > don't want that, especially since the method invocation timeouts on the
> > client side are not particularly long.
> >
> The timeout case is the same as, for example, Upstart itself not
> connecting to the bus.
> All method calls are generally subject to a timeout; the default, as
> you say, is pretty low.  So the worst case here is that you send a
> method call, D-Bus is selected to use Upstart for activation, it sends
> an activation message to Upstart, which times out so the client gets a
> time out.
> As far as I can see, this is the same as the systemd path.  The only
> difference is you explicitly signal D-Bus on activation failure within
> that timeout, whereas Upstart doesn't.

Well, it's a pretty major difference between the Upstart and the
systemd/classic paths if in case the service fails to start (perhaps due
to an invalid configuration file) on Upstart you have to wait 2 mins and
the system stays stuck and then get a misleading error message which
says something timed out, and on systemd/classic paths you get an
immediate error message explaining the situation.

In fact, I would call the Upstart glue pretty much broken if every
service startup error is turned into a 2min delay plus a misleading
error message. Proper error handling matters. Things fail, you need to
have minimal, and proper handling of errors.


Lennart Poettering - Red Hat, Inc.

More information about the dbus mailing list