On Wed, Apr 11, 2012 at 01:08:24AM +0200, Michael Biebl wrote: > >>> It would; I just don't think invoke-rc.d is the right place for that > >>> complexity to live. For instance: if upstart is running, there's an > >>> upstart job for foo, job foo is not running, and invoke-rc.d calls > >>> /etc/init.d/foo stop as a fallback: how should invoke-rc.d handle the > >>> exit code of /etc/init.d/foo? > >>> All possible answers to that question are sufficiently irksome that I > >>> think we should avoid putting the complexity in invoke-rc.d. > >> invoke-rc.d already needs to be upstart aware, so this seems like the > >> right place to put this logic imho. Putting it in each and every sysv > >> init script on the other hand looks wrong to me. > > You didn't actually answer the question I posed here. How should > > invoke-rc.d handle the exit code of /etc/init.d/foo to make this not suck in > > the corner cases? > What specific problems do you have in mind here. It's not really > possible to answer the question for some hypothetical issue. Maintainer script calls invoke-rc.d foo stop. invoke-rc.d looks for a 'foo' upstart job and finds none running. So it calls /etc/init.d/foo stop, which fails. Does invoke-rc.d return success because there was no upstart job running, or failure because the init script failed? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature