Code review comment for lp:~jamesodhunt/upstart/bug-901038

>Should there be some kind of timeout, say a minute or so to catch the unlikely case where upstart
> is messed up an never starts listening again on dbus?
I can understand the concern, but I don't think we can realistically provide a timeout as we don't know what a reasonable re-exec time is in all circumstances: infinity's >1 minute re-exec time was clearly the result of a bug (bug 1338637), but the re-exec _did_ complete correctly - it just took a very long time.

Also, telinit is connecting to the private D-Bus socket and if that isn't available, Upstarts capabilities are then severly restricted.

> Also, you mention that a rejected reexec request is unlikely, but what happens if a non-root user
> does it, wouldn't that fail and then have the rest of the code return success anyway?
If a non-root user runs 'telinit u', they get rejected immediately as telinit ensures the user running the command is root. I think the only scenarios where the re-exec request would be rejected are:

1) Where telinit is attempting to talk to an old version of upstart that doesn't support re-exec.
   We can ignore this scenario as we don't support down-grade scenarios.

2) Where telinit is attempting to talk to a non-Upstart init daemon.

   I guess this could be an issue in Ubuntu, depending on exactly how we manage the init
   transition. However, we should be able to arrange for maintainer scripts to set
   UPSTART_TELINIT_U_NO_WAIT to avoid that issue.