>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. -- https://code.launchpad.net/~jamesodhunt/upstart/bug-901038/+merge/231705 Your team Upstart Reviewers is requested to review the proposed merge of lp:~jamesodhunt/upstart/bug-901038 into lp:upstart. -- upstart-devel mailing list upstart-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
