Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

Steve Langasek writes: > If I understand the policy process correctly, the N=3 requirement for > patches includes the submitter; so with two other seconds, I think this > is ready to go. I have merged this patch for the next release. Thanks! While I think we can improve this documentation as w

Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

Jonathan Nieder writes: > Thanks! Here's a copy for reference. I take it from the rest of your > reply that you still second it. > (I haven't carefully reviewed the patch or later discussion yet myself.) I also still second it; I think it's time to get this into Policy, and we can deal with a

Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

Steve Langasek wrote: > The current patch is the one at > . Thanks! Here's a copy for reference. I take it from the rest of your reply that you still second it. (I haven't carefully reviewed the patch or later discussion yet myself.)

Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

On Mon, Aug 27, 2012 at 11:10:53AM -0700, Jonathan Nieder wrote: > > If I understand the policy process correctly, the N=3 requirement for > > patches includes the submitter; so with two other seconds, I think this is > > ready to go. > There was an objection from Michael Biebl True. But when p

Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

Steve Langasek wrote: > If I understand the policy process correctly, the N=3 requirement for > patches includes the submitter; so with two other seconds, I think this is > ready to go. There was an objection from Michael Biebl and quite a bit of discussion after those seconds which touched on im

Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

user debian-pol...@packages.debian.org usertag 591791 seconded thanks If I understand the policy process correctly, the N=3 requirement for patches includes the submitter; so with two other seconds, I think this is ready to go. -- Steve Langasek Give me a lever long enough and

Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

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/in

Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

On 10.04.2012 01:07, Steve Langasek wrote: I'm wondering if this couldn't be handled in invoke-rc.d though. If upstart is running, and there is a native upstart job, which is not running though, invoke-rc.d could just call /etc/init.d/foo stop > In postinst, when you run invoke

Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

Oh right, should've answered this mail together with the previous, sorry. On Fri, Mar 16, 2012 at 10:46:38PM +0100, Michael Biebl wrote: > > If invoke-rc.d intercepts and redirects the request to upstart (or > > systemd), should update-rc.d do the same? > > Say you run "update-rc.d disable", sho

Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

On Fri, Mar 16, 2012 at 10:05:32PM +0100, Michael Biebl wrote: > >> What happens in maintainers scripts that call invoke-rc.d service start? > >> Will they now suddenly all fail? How will invoke-rc.d behave when the > >> package both installs a upstart job and sysv init script? > > Doesn't this la

Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

On Fri, Mar 16, 2012 at 11:33:26PM +0100, Michael Biebl wrote: > >> Fwiw, this is a non-issue for systemd, as it treats sysv services and > >> native services alike. So during the upgrade, the old sysv based service > >> is stopped, systemd reloads the service definitions and sees that there > >> i

Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

]] Jonathan Nieder > Russ Allbery wrote: > > > That seems like a feature, not a bug, in the case of configuration > > installed by Debian packages such as what's cited in this part of the > > thread. If I have a policy rule that says not to run that init script, I > > mean it, and I don't want

Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

]] Michael Biebl > Do we "somehow" ensure the on/off state of the service is kept > consistent between the different init systems, so it doesn't matter > when I switch from sysvinit to upstart (or back again)? Yes, I think it's fairly obvious we need to keep the set of services enabled/disabled

Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

On Fri, Mar 16, 2012 at 03:14:18PM -0500, Jonathan Nieder wrote: > By the way, the above example writes the path to initctl to the > terminal when it is present, which I imagine is not intended. Indeed not. Updated example in the attached patch. > [...] > > Also, the proposal looks underspecifi

Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

On Fri, Mar 16, 2012 at 5:07 PM, Russ Allbery wrote: > Michael Biebl writes: >> How will "service" behave? > > service already handles upstart directly.  It presumably could and should > be extended in an equivalent way to handle systemd.  I don't think that > needs to be spelled out in Policy, s

Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

On 16.03.2012 23:12, Steve Langasek wrote: > On Fri, Mar 16, 2012 at 10:57:20PM +0100, Michael Biebl wrote: Personally, I would just prefer, if the shell library would forward the action requests to the native init system. > >>> But this falls down horribly during the upgrade in a very e

Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

On Fri, Mar 16, 2012 at 10:57:20PM +0100, Michael Biebl wrote: > >> Personally, I would just prefer, if the shell library would forward the > >> action requests to the native init system. > > But this falls down horribly during the upgrade in a very error-prone > > manner. > Fwiw, this is a non-i

Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

On 16.03.2012 22:28, Steve Langasek wrote: > On Fri, Mar 16, 2012 at 09:25:17PM +0100, Michael Biebl wrote: >>> Well, it would be inappropriate to refuse to stop the service because >>> upstart was running. The more likely outcome is that the init script >>> will not be able to find the running pr

Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

On Fri, Mar 16, 2012 at 04:19:15PM -0500, Jonathan Nieder wrote: > Example for context: > http://bugs.debian.org/445203#50 > Which points to: > http://bugs.debian.org/588085 Given that there's a separate policy bug for this, I'm not sure what bearing this has on the upstart discussion. Cou

Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

Steve Langasek writes: > I think this should all go in the lsb-base package (bug #661109). > That's already a "standard" shell library for init scripts, which > includes lots of functions that aren't part of the LSB standard; I don't > see a good reason to contribute to a proliferation of shell l

Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

On 16.03.2012 22:05, Michael Biebl wrote: > If invoke-rc.d intercepts and redirects the request to upstart (or > systemd), should update-rc.d do the same? > > Say you run "update-rc.d disable", should this disable only > the sysv init script, both, or only the upstart/systemd service? The reaso

Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

On 16.03.2012 22:08, Steve Langasek wrote: > It also rubs me the wrong way to have the shell library exiting directly > from the init script. I'd really prefer an interface such as > init_is_upstart() which leaves it open for the init script to handle some of > the mentioned corner cases - in par

Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

On Fri, Mar 16, 2012 at 09:25:17PM +0100, Michael Biebl wrote: > > Well, it would be inappropriate to refuse to stop the service because > > upstart was running. The more likely outcome is that the init script > > will not be able to find the running process, and will therefore exit 0 > > anyway a

Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

Russ Allbery wrote: > That seems like a feature, not a bug, in the case of configuration > installed by Debian packages such as what's cited in this part of the > thread. If I have a policy rule that says not to run that init script, I > mean it, and I don't want ifup running it anyway. It's jus

Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

On 16.03.2012 22:08, Steve Langasek wrote: > On Fri, Mar 16, 2012 at 01:07:08PM -0700, Russ Allbery wrote: >> If upstart and systemd can agree on the same invocation semantics for the >> shell library, we could even provide a shell library that handled both and >> make this more generic. > > I th

Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

On Fri, Mar 16, 2012 at 01:07:08PM -0700, Russ Allbery wrote: > This seems like a reasonable idea. Steve, what do you think of having > upstart provide such a shell library? Then init scripts could contain > code along the lines of: > if [ -r /lib/init/upstart.sh ] ; then > . /lib/i

Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

On 16.03.2012 21:18, Steve Langasek wrote: >> What happens in maintainers scripts that call invoke-rc.d service start? >> Will they now suddenly all fail? How will invoke-rc.d behave when the >> package both installs a upstart job and sysv init script? > > Doesn't this language already cover that

Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

Jonathan Nieder writes: > Russ Allbery wrote: >> This probably should already be a Policy violation, saying that they >> should use invoke-rc.d instead. Is there any drawback to them using >> invoke-rc.d? > Yes, I think there is a drawback. Forgetting about upstart and systemd > for the moment

Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

On 16.03.2012 21:25, Michael Biebl wrote: > Personally, I would just prefer, if the shell library would forward the > action requests to the native init system. I still like this part of the original upstart-job idea (Steve knows the details), simply because admins are used to the /etc/init.d/ i

Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

Russ Allbery wrote: > This probably should already be a Policy violation, saying that they > should use invoke-rc.d instead. Is there any drawback to them using > invoke-rc.d? Yes, I think there is a drawback. Forgetting about upstart and systemd for the moment, if I use "/etc/init.d/ start" or

Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

Michael Biebl writes: > Another problematic issue that comes to mind, is packages installing > dhcp and ifup.d hooks which call /etc/init.d/ > From my recollection, there are at least a few that do this, the most > prominent one is nfs-common. This probably should already be a Policy violation

Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

On 16.03.2012 21:18, Steve Langasek wrote: > On Fri, Mar 16, 2012 at 08:53:15PM +0100, Michael Biebl wrote: > >> As I've already mentioned before, I don't like the approach, that any >> init script should use something like: > >>> if [ "$1" = start ] && which initctl && initctl version | grep -q

Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

On Fri, Mar 16, 2012 at 08:53:15PM +0100, Michael Biebl wrote: > As I've already mentioned before, I don't like the approach, that any > init script should use something like: > > if [ "$1" = start ] && which initctl && initctl version | grep -q upstart; > > then > > exit 1 > > then > It seems

Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

Hi Michael, Michael Biebl wrote: > As I've already mentioned before, I don't like the approach, that any > init script should use something like: > >> if [ "$1" = start ] && which initctl && initctl version | grep -q upstart >> then >> exit 1 >> fi > > It seems much more sensible to me, to m

Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

Michael Biebl writes: > It seems much more sensible to me, to move all this logic into a > separate shell library, and instead of hardcoding the above commands in > the sysv init script, policy should just mention that maintainers that > wish to provide both an upstart job and sysv init script wo

Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

On 16.03.2012 20:09, Adam D. Barratt wrote: > On Sun, 2012-02-26 at 17:01 -0800, Steve Langasek wrote: >> On Sun, Feb 26, 2012 at 04:00:11PM -0800, Russ Allbery wrote: >>> Oh, yes, I misunderstood that too. How about: >> >>> These maintainer scripts must not call the upstart >>> st

Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

On Sun, 2012-02-26 at 17:01 -0800, Steve Langasek wrote: > On Sun, Feb 26, 2012 at 04:00:11PM -0800, Russ Allbery wrote: > > Oh, yes, I misunderstood that too. How about: > > > These maintainer scripts must not call the upstart > > start, restart, reload, or > > stop inter

Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

Steve Langasek writes: > On Sun, Feb 26, 2012 at 04:00:11PM -0800, Russ Allbery wrote: >> Oh, yes, I misunderstood that too. How about: >> These maintainer scripts must not call the upstart >> start, restart, reload, or >> stop interfaces directly. >> which uses the sam

Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

On Sun, Feb 26, 2012 at 04:00:11PM -0800, Russ Allbery wrote: > Steve Langasek writes: > > I think you've misunderstood the intent here. When upstart is > > installed, it provides *commands* called "start", "restart", "reload", > > and "stop" in /sbin. These are the commands that must not be ca

Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

Steve Langasek writes: > I think you've misunderstood the intent here. When upstart is > installed, it provides *commands* called "start", "restart", "reload", > and "stop" in /sbin. These are the commands that must not be called > from maintainer scripts. It has nothing to do with invocation

Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

On Sun, Feb 26, 2012 at 05:12:24PM -0600, Jonathan Nieder wrote: > > --- a/policy.sgml > > +++ b/policy.sgml > > @@ -7188,6 +7188,74 @@ Reloading description > > configuration...done. > [...] > > + > > +Because packages shipping upstart jobs may be installed on > > +

Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

Steve Langasek wrote: > --- a/policy.sgml > +++ b/policy.sgml > @@ -7188,6 +7188,74 @@ Reloading description configuration...done. [...] > + > +Because packages shipping upstart jobs may be installed on > +systems that are not using upstart, maintainer scripts mus