[Merge] lp:~jamesodhunt/upstart/bug-901038 into lp:upstart

Steve Langasek steve.langasek at canonical.com
Thu Sep 4 18:53:59 UTC 2014


Review: Needs Fixing

> 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.

I don't think any solution should require maintainer scripts to set an extra variable to get sane behavior out of telinit.

If telinit is trying to talk to a non-upstart init, shouldn't it know it?  In that case, it surely should not wait for a reconnect on an upstart-specific private socket, but should automatically fall back gracefully to a non-blocking restart.

However, the current upstart 'telinit u' code simply exits non-zero when pid 1 is not upstart - as does the proposed new code.  So this is something we need to deal with if/when adding support for telinit u on top of non-upstart pid 1, but not something that should block this change now.

Given this, what is the expected use case for "UPSTART_TELINIT_U_NO_WAIT"?  If you don't have a concrete user for this, please omit.  Unnecessary interfaces always carry an incremental cost, and I can't see any case where it would ever be correct to use this interface, so this looks like overengineering to me.

Otherwise, this looks fine to me for merging.
-- 
https://code.launchpad.net/~jamesodhunt/upstart/bug-901038/+merge/231705
Your team Upstart Reviewers is subscribed to branch lp:upstart.



More information about the upstart-devel mailing list