On Wed, Jan 12, 2011 at 07:38:05PM +0100, Kurt Roeckx wrote: > On Wed, Jan 12, 2011 at 12:50:21AM -0600, Steve Langasek wrote: > > On Mon, Jan 10, 2011 at 09:17:33PM +0100, Kurt Roeckx wrote:
> > > What should packages do that want to have their script run
> > > at that time? For sysvinit scripts this is calling update-rc.d
> > > with S as the runlevel. I don't know if the alternatives
> > > support something like a runlevel, and which they support.
> > I think this is covered already by requiring alternative init
> > implementations to support running sysvinit scripts - rcS.d is definitely
> > part of this, just as rc[0-6].d are. Do you think we should be more
> > explicit about the supported runlevels? (It's awkward to talk about
> > rc[0-6].d directly, precisely because this is an internal detail of sysv-rc
> > vs. file-rc)
> So you're saying that rcS.d and rc[0-6].d will keep existing? I assumed
> it wouldn't exist anymore, or atleast not for all cases, and that
> update-rc.d would do something with it that's specific to the init
> system.
I'm saying that SysV *runlevels* will continue to exist. Whether or not the
rc{S,0-6}.d *directories* continue to exist is an implementation detail for
update-rc.d to sort through (and we already have update-rc.d implementations
in the archive that don't use these symlinks), but init systems and packages
must still continue to be able to interface with each other this way
(packages by declaring when their scripts should be run with start/stop
arguments; init systems by running those scripts at the appropriate time).
> > > /etc/init seems to be a very general directory name for an upstart job.
> > > Can the alternatives use the same job files as upstart?
> > I don't believe any alternatives use the same job files today.
> [...]
> > In any event, my intent here is to document the behavior required for
> > interoperability, and this documents the behavior required for
> > interoperability with the existing upstart package.
> Shouldn't that be part of the upstart documentation in that case
> instead of policy?
There are over 100 upstart jobs (not including those in the upstart package
itself) in Ubuntu today, and I fully expect these to flood into Debian once
the gates are opened. This is not a matter of a small number of packages
coming up with a private interface for interoperation; it's going to have a
broad impact, and that's the sort of thing we document in Policy.
If you think that upstart should be *mandated* to use a different directory
instead of /etc/init, then Policy is the place to do that, too; I just can't
see any justification for such an override.
> > > If I understand you right, if the package supports something
> > > other than sysvinit, the file in /etc/init.d/ should check that
> > > any of those is currently used?
> > Yep!
> > > And it should just return 0?
> > I think it needs to return non-zero for purposes of robustness - otherwise
> > the init script will give false-positives to callers that expect the init
> > script to be useful when it isn't.
> Which callers do you have in mind? Shouldn't they be using
> invoke-rc.d instead?
invoke-rc.d is an interface for maintainer scripts. Admins are known to
call init scripts directly; cluster management tools may do likewise, though
it's also possible these will use invoke-rc.d instead.
If nothing else, an init script that returns success on 'start' without
starting the service would be inconsistent with how we've expected all init
scripts to work to date. (It's not *quite* a policy violation, but near
enough to.) And if you argue that nothing should ever call these init
scripts because everything should use invoke-rc.d, then things using this
upstart-aware interface will never see the return code anyway, right?
> > > I wonder if it would be useful to call invoke-rc.d instead
> > > in that case if it's run by a user.
> > Sorry, I don't follow this, can you elaborate?
> I was thinking about cases who calls the /etc/init.d/ scripts,
> and only thought of:
> - The init system
> - invoke-rc.d
> - A user (that doesn't know that upstart is being used)
> And the rest should be using invoke-rc.d. invoke-rc.d
> shouldn't call that script if a job exists for it. For
> the user it would be handy that it called invoke-rc.d instead,
> or atleast give a message it should't be called directly.
No, definitely not. It's important that admins have the capability of
manually starting services out of runlevel, and for this the (historical)
interface is to invoke the init script directly. (Nowadays, I would argue
that these admins should use the 'service' command instead, for which
upstart-aware patches already exist. However, the 'service' interface is a
relatively recent addition to Debian, and I expect many admins are still
invoking init scripts directly.)
Cheers,
--
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/
slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
