Bug#591791: extend init.d policy to permit upstart jobs and describe their use
Hi Jonathan, On Sat, Mar 05, 2011 at 02:19:12AM -0600, Jonathan Nieder wrote: + tasks at boot time. However, any package integrating with other + init systems must also be backwards-compatible with + packagesysvinit/package by providing a SysV-style init script + with the same name as and equivalent functionality to any + init-specific job, as this is the only start-up configuration + method guaranteed to be supported by all init implementations. An + exception to this rule is scripts or jobs provided by the init + implementation itself; such jobs may be required for an + implementation-specific equivalent of the file/etc/rcS.d//file + scripts and may not have a one-to-one correspondence with the init + scripts. Maybe policy could allow (but discourage) packages that only support some non-Sys-V init system as long as they include a dependency indicating so? I don't think that's something that should be allowed. You can only have one init system installed at a time; and all of the interesting alternatives to sysvinit are currently Linux-only. So if maintainers start choosing to only support one of the alternatives, they will quickly fragment the distribution (because not all maintainers are going to choose the *same* alternative), and they will render their packages unusable on our non-Linux ports. The only reason for any package to provide only an upstart job, or only a systemd config, is if it's a cooperating package providing part of the base boot sequence for that init system. (E.g., mountall for upstart.) One of the advantages of upstart and its kin is the simpler configuration, after all, so I can imagine some maintainers wanting to take advantage of that and not having time to debug a standard init script. The example that led me to mention this is Bug#422139; it is not quite the same issue but is related. Having written many upstart jobs, I understand the appeal of not having to maintain a sysvinit script for backwards-compatibility. However, the slow movement of upstart in Debian so far, and this policy bug proposing rules for alternate init systems, are specifically about ensuring that we do *not* lose backwards-compatibility. Now, if someone were to write a tool to automatically translate an upstart job into an init script, that might be an interesting way to handle this; but most upstart jobs will be missing information about things like how to ask a daemon to create a pid file, or where the pid file will be stored, so the applications might still be limited. As a naïve user, I'd prefer the SysV init scripts to pass on requests to upstart when upstart is running; is that feasible? It would be feasible to pass requests to upstart, but it would be unnecessary. If the upstart job is properly declared, upstart will have already started it in the runlevel (or queued it for starting) before the init script ever has a chance to ask; and for admin invocations, a frontend like the 'service' command is more user-friendly anyway. I suspect it would be best to make the language init system neutral, and to say something to this effect: . sysvinit scripts need to behave reasonably regardless of the init system in use. So: i. If an equivalent job file for another init system is present, the sysvinit script will not be automatically invoked by that init system when switching runlevels. In this case, when that init system is in use, the sysvinit script (if invoked by hand, for example) must either delegate requests to the init system or error out without doing anything. Don't fight with init(8). ii. Even if an equivalent job file for another init system is available, the sysvinit script should behave as advertised (and not be a no-op) when init is sysvinit. I agree that these are the relevant principles, but I think Policy should spell out exact requirements for each init system. 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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#591791: extend init.d policy to permit upstart jobs and describe their use
Hi, Steve Langasek wrote: On Sat, Mar 05, 2011 at 02:19:12AM -0600, Jonathan Nieder wrote: Maybe policy could allow (but discourage) packages that only support some non-Sys-V init system as long as they include a dependency indicating so? I don't think that's something that should be allowed. You can only have one init system installed at a time Exactly. That makes this old suggestion of mine a very bad idea, and I'm glad you caught it back then, too. ;-) [...] As a naïve user, I'd prefer the SysV init scripts to pass on requests to upstart when upstart is running; is that feasible? [...] for admin invocations, a frontend like the 'service' command is more user-friendly anyway. I don't agree, but I agree that it's not worth the fuss to teach /etc/init.d/foo to pass on requests and handle all edge cases appropriately, so this is academic. [...] . sysvinit scripts need to behave reasonably regardless of the init system in use. So: i. If an equivalent job file for another init system is present, the sysvinit script will not be automatically invoked by that init system when switching runlevels. In this case, when that init system is in use, the sysvinit script (if invoked by hand, for example) must either delegate requests to the init system or error out without doing anything. Don't fight with init(8). ii. Even if an equivalent job file for another init system is available, the sysvinit script should behave as advertised (and not be a no-op) when init is sysvinit. I agree that these are the relevant principles, but I think Policy should spell out exact requirements for each init system. I guess so. (ii) is already implied by don't be buggy. (i) is probably worth spelling out, though --- I'll look at your patch to see if it does so. In an ideal world, (i) would be enough [since it determines the behavior] and packagers could experiment and refer to each init system's interface documentation [e.g. manpages] for details, but I understand that documenting details on implementation strategy in one place can be useful for making the result easy to understand. Thanks again for your work on this! Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591791: extend init.d policy to permit upstart jobs and describe their use
Jonathan Nieder wrote: In an ideal world, (i) would be enough [since it determines the behavior] and packagers could experiment Just to be clear: I was reading from the point of view of what a packager of an ordinary daemon needs to do. But the requirements on init systems are important, too[1]. Sorry about neglecting that. [1] Examples: to what extent an init system is allowed to ignore init scripts provided by other packages when it provides its own native equivalents. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591791: extend init.d policy to permit upstart jobs and describe their use
Hi, Steve Langasek wrote: Sorry this has taken so long; I spun my wheels on it for some time because I couldn't quite accept that there were so few additional requirements that needed to be specified here! Thanks for your work. :) [...] + tasks at boot time. However, any package integrating with other + init systems must also be backwards-compatible with + packagesysvinit/package by providing a SysV-style init script + with the same name as and equivalent functionality to any + init-specific job, as this is the only start-up configuration + method guaranteed to be supported by all init implementations. An + exception to this rule is scripts or jobs provided by the init + implementation itself; such jobs may be required for an + implementation-specific equivalent of the file/etc/rcS.d//file + scripts and may not have a one-to-one correspondence with the init + scripts. Maybe policy could allow (but discourage) packages that only support some non-Sys-V init system as long as they include a dependency indicating so? One of the advantages of upstart and its kin is the simpler configuration, after all, so I can imagine some maintainers wanting to take advantage of that and not having time to debug a standard init script. The example that led me to mention this is Bug#422139; it is not quite the same issue but is related. + SysV init scripts for which +an equivalent upstart job is available must query the output of +the command prgntelinit --version/prgn for the string +ttupstart/tt As Tollef mentioned, upstart can be installed without being init. This currently spews a usage string to stderr on sysvinit. I wonder if there is some other way to ask init whether it is upstart? As a naïve user, I'd prefer the SysV init scripts to pass on requests to upstart when upstart is running; is that feasible? I suspect it would be best to make the language init system neutral, and to say something to this effect: . sysvinit scripts need to behave reasonably regardless of the init system in use. So: i. If an equivalent job file for another init system is present, the sysvinit script will not be automatically invoked by that init system when switching runlevels. In this case, when that init system is in use, the sysvinit script (if invoked by hand, for example) must either delegate requests to the init system or error out without doing anything. Don't fight with init(8). ii. Even if an equivalent job file for another init system is available, the sysvinit script should behave as advertised (and not be a no-op) when init is sysvinit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591791: extend init.d policy to permit upstart jobs and describe their use
On Sat, Mar 05, 2011 at 02:19:12AM -0600, Jonathan Nieder wrote: Hi, Steve Langasek wrote: Sorry this has taken so long; I spun my wheels on it for some time because I couldn't quite accept that there were so few additional requirements that needed to be specified here! Thanks for your work. :) [...] + tasks at boot time. However, any package integrating with other + init systems must also be backwards-compatible with + packagesysvinit/package by providing a SysV-style init script + with the same name as and equivalent functionality to any + init-specific job, as this is the only start-up configuration + method guaranteed to be supported by all init implementations. An + exception to this rule is scripts or jobs provided by the init + implementation itself; such jobs may be required for an + implementation-specific equivalent of the file/etc/rcS.d//file + scripts and may not have a one-to-one correspondence with the init + scripts. Maybe policy could allow (but discourage) packages that only support some non-Sys-V init system as long as they include a dependency indicating so? This would be a terrible idea. We would end up with packages that will not be work together because they depend on different init systems. One of the advantages of upstart and its kin is the simpler configuration, after all, so I can imagine some maintainers wanting to take advantage of that and not having time to debug a standard init script. The example that led me to mention this is Bug#422139; it is not quite the same issue but is related. The whole point of Debian policy is to promote interoperability, not to allow maintainer to make quick-and dirty packages. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591791: extend init.d policy to permit upstart jobs and describe their use
Bill Allombert wrote: On Sat, Mar 05, 2011 at 02:19:12AM -0600, Jonathan Nieder wrote: Maybe policy could allow (but discourage) packages that only support some non-Sys-V init system as long as they include a dependency indicating so? This would be a terrible idea. We would end up with packages that will not be work together because they depend on different init systems. Very good point. Sorry, I wasn't thinking straight. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591791: extend init.d policy to permit upstart jobs and describe their use
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
Bug#591791: extend init.d policy to permit upstart jobs and describe their use
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: On Sun, Jan 09, 2011 at 08:10:04PM -0600, Steve Langasek wrote: + method guaranteed to be supported by all init implementations. An + exception to this rule is scripts or jobs provided by the init + implementation itself; such jobs may be required for an + implementation-specific equivalent of the file/etc/rcS.d//file + scripts and may not have a one-to-one correspondence with the init + scripts. +/p A lot of the scripts currently in /etc/rcS.d/ come from the initscripts package. Is the alternative supposed to implement all the functionality by those scripts? Or do we expect them to run the scripts from /etc/rcS.d/ as 9.3.4. seems to suggest? Well, the initscripts package in Ubuntu does provide one script that's run in /etc/rcS.d (urandom) and several other scripts that are run in other runlevels (some in 0/6; some in 1; some in 2 3 4 5). But there's definitely a delta in the initscripts package when used with sysvinit vs. upstart. I'm not sure if this is something that needs to be specified in policy though, as opposed to just being worked through in the implementation. I'm fine with leaving it up to the implementation on exactly which part it does itself and which it takes from initscripts or somewhere else. But what I do expect is that in the end the system is in the same state, and I guess I sometimes think too much about the details of how this is supposed to happen. Does Ubuntu just ship a package with less scripts in initscripts, or does upstart lists somewhere which ones it wants or doesn't want? 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. +sect1 id=upstart + headingEvent-based boot with upstart/heading + + p +Packages may integrate with the prgnupstart/prgn event-based +boot system by installing job files in the +file/etc/init/file directory. /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? SysV init scripts for which +an equivalent upstart job is available must query the output of +the command prgntelinit --version/prgn for the string +ttupstart/tt and avoid running in favor of the native +upstart job. [...] 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? 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. But maybe some 3rd party applications might also be calling it directly. What I miss in policy is a description of update-rc.d. We currently seem to have 2 implementations (each with it's manpage) of it while I was expecting each alternative to implement this. And I guess the same
Bug#591791: extend init.d policy to permit upstart jobs and describe their use
On Wed, Jan 12, 2011 at 6:38 PM, Kurt Roeckx k...@roeckx.be 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: A lot of the scripts currently in /etc/rcS.d/ come from the initscripts package. Is the alternative supposed to implement all the functionality by those scripts? Or do we expect them to run the scripts from /etc/rcS.d/ as 9.3.4. seems to suggest? Well, the initscripts package in Ubuntu does provide one script that's run in /etc/rcS.d (urandom) and several other scripts that are run in other runlevels (some in 0/6; some in 1; some in 2 3 4 5). But there's definitely a delta in the initscripts package when used with sysvinit vs. upstart. I'm not sure if this is something that needs to be specified in policy though, as opposed to just being worked through in the implementation. I'm fine with leaving it up to the implementation on exactly which part it does itself and which it takes from initscripts or somewhere else. But what I do expect is that in the end the system is in the same state, and I guess I sometimes think too much about the details of how this is supposed to happen. Does Ubuntu just ship a package with less scripts in initscripts, or does upstart lists somewhere which ones it wants or doesn't want? The Ubuntu initscripts package contains fewer and modified scripts (the plan is for it to not exist at all), since the conversion has been made for those tasks to be performed by Upstart jobs. (Systemd largely has support for those tasks built-in) 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 would have thought that rcS.d/rc[0-6].d are not compulsory parts, as replacement init systems may simply read the LSB headers from the top and allow them to be overridden in some way. To me, the update-rc.d/chkconfig style standard is the right one. Scott -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591791: extend init.d policy to permit upstart jobs and describe their use
On Mon, Jan 10, 2011 at 09:17:33PM +0100, Kurt Roeckx wrote:
On Sun, Jan 09, 2011 at 08:10:04PM -0600, Steve Langasek wrote:
Also, it's possible that some of the bits I've marked as upstart-specific
will also be applicable to systemd and should be moved up a section. I'm
not familiar enough with the mechanics of systemd to say whether this is the
case; eyeballs/wording tweaks welcome.
Next to upstart and systemd we currently also have file-rc and runit
as alternatives to sysvinit. But runit-run doesn't seem to exist
anymore?
file-rc is an alternative to sysv-rc, not to sysvinit; you still need
sysvinit installed if you use file-rc, and init.d scripts are the only
startup job format supported by either sysv-rc or file-rc. So I don't think
file-rc needs to be mentioned here?
runit-run seems to not be in squeeze, yes.
+ method guaranteed to be supported by all init implementations.
An
+ exception to this rule is scripts or jobs provided by the init
+ implementation itself; such jobs may be required for an
+ implementation-specific equivalent of the
file/etc/rcS.d//file
+ scripts and may not have a one-to-one correspondence with the
init
+ scripts.
+/p
A lot of the scripts currently in /etc/rcS.d/ come from the
initscripts package. Is the alternative supposed to implement
all the functionality by those scripts? Or do we expect them
to run the scripts from /etc/rcS.d/ as 9.3.4. seems to suggest?
Well, the initscripts package in Ubuntu does provide one script that's run
in /etc/rcS.d (urandom) and several other scripts that are run in other
runlevels (some in 0/6; some in 1; some in 2 3 4 5). But there's definitely
a delta in the initscripts package when used with sysvinit vs. upstart. I'm
not sure if this is something that needs to be specified in policy though,
as opposed to just being worked through in the implementation.
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)
+sect1 id=upstart
+ headingEvent-based boot with upstart/heading
+
+ p
+Packages may integrate with the prgnupstart/prgn
event-based
+boot system by installing job files in the
+file/etc/init/file directory.
/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.
Yes, /etc/init is a generic name. /etc/init.d is also. I realize this
smacks of arrogance to put upstart on an equal footing with an init system
that's been established for 20+ years, but frankly, the Unix namespace has
always been first-come, first-serve, and when upstart adopted this
convention there were no credible alternatives competing for the namespace
anyway. And although I've seen systemd proponents complain about this
namespace pollution, it doesn't seem to be due to any desire that systemd
*itself* use it, so there's not really a conflict.
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. If you think upstart
shouldn't use this directory path, please take it up with the upstart
maintainer. :)
SysV init scripts for which
+an equivalent upstart job is available must query the output of
+the command prgntelinit --version/prgn for the string
+ttupstart/tt and avoid running in favor of the native
+upstart job.
telinit --version with sysvinit now returns:
telinit: invalid option -- '-'
Usage: telinit {-e VAR[=VAL] | [-t SECONDS]
{0|1|2|3|4|5|6|S|s|Q|q|A|a|B|b|C|c|U|u}}
What kind of output would you expect from it?
with current upstart:
$ telinit --version
telinit (upstart 0.6.6)
Copyright (C) 2010 Canonical Ltd.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$
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
Bug#591791: extend init.d policy to permit upstart jobs and describe their use
On Sun, Jan 09, 2011 at 08:10:04PM -0600, Steve Langasek wrote:
Also, it's possible that some of the bits I've marked as upstart-specific
will also be applicable to systemd and should be moved up a section. I'm
not familiar enough with the mechanics of systemd to say whether this is the
case; eyeballs/wording tweaks welcome.
Next to upstart and systemd we currently also have file-rc and runit
as alternatives to sysvinit. But runit-run doesn't seem to exist
anymore?
+ method guaranteed to be supported by all init implementations. An
+ exception to this rule is scripts or jobs provided by the init
+ implementation itself; such jobs may be required for an
+ implementation-specific equivalent of the file/etc/rcS.d//file
+ scripts and may not have a one-to-one correspondence with the init
+ scripts.
+/p
A lot of the scripts currently in /etc/rcS.d/ come from the
initscripts package. Is the alternative supposed to implement
all the functionality by those scripts? Or do we expect them
to run the scripts from /etc/rcS.d/ as 9.3.4. seems to suggest?
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.
+sect1 id=upstart
+ headingEvent-based boot with upstart/heading
+
+ p
+Packages may integrate with the prgnupstart/prgn event-based
+boot system by installing job files in the
+file/etc/init/file directory.
/etc/init seems to be a very general directory name for an upstart job.
Can the alternatives use the same job files as upstart?
SysV init scripts for which
+an equivalent upstart job is available must query the output of
+the command prgntelinit --version/prgn for the string
+ttupstart/tt and avoid running in favor of the native
+upstart job.
telinit --version with sysvinit now returns:
telinit: invalid option -- '-'
Usage: telinit {-e VAR[=VAL] | [-t SECONDS]
{0|1|2|3|4|5|6|S|s|Q|q|A|a|B|b|C|c|U|u}}
What kind of output would you expect from it?
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? And it should just return 0?
I wonder if it would be useful to call invoke-rc.d instead
in that case if it's run by a user.
+ /p
+ p
+Because packages shipping upstart jobs may be installed on
+systems that are not using upstart, maintainer scripts must
+still use the common prgnupdate-rc.d/prgn and
+prgninvoke-rc.d/prgn interfaces for configuring runlevels
+and for starting and stopping services. These maintainer
+scripts must not call the prgnstart/prgn,
+prgnrestart/prgn, prgnreload/prgn, or prgnstop/prgn
+commands directly.
That's already covered by 9.3.3.2? (But could use rewording.)
What I miss in policy is a description of update-rc.d. We
currently seem to have 2 implementations (each with it's
manpage) of it while I was expecting each alternative to
implement this. And I guess the same goes for invoke-rc.d.
9.3.3.1. could use a re-write as it also seems to be sysvinit
specific.
Kurt
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591791: extend init.d policy to permit upstart jobs and describe their use
On Mon, Jan 10, 2011 at 8:17 PM, Kurt Roeckx k...@roeckx.be wrote: + method guaranteed to be supported by all init implementations. An + exception to this rule is scripts or jobs provided by the init + implementation itself; such jobs may be required for an + implementation-specific equivalent of the file/etc/rcS.d//file + scripts and may not have a one-to-one correspondence with the init + scripts. + /p A lot of the scripts currently in /etc/rcS.d/ come from the initscripts package. Is the alternative supposed to implement all the functionality by those scripts? Or do we expect them to run the scripts from /etc/rcS.d/ as 9.3.4. seems to suggest? Well, in the systemd case, all the things those scripts used to do are built in and hardcoded in systemd itself. And in the Upstart case, there is a separate implementation of those as well. So yes, I think an init system should deal with core boot by itself, as sysvinit does with the initscripts package. I guess this means policy needs to specify what needs to be done ;-) (otherwise people may find they get a shock if systemd's hardcoded mounting doesn't match what they expected) Scott -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591791: extend init.d policy to permit upstart jobs and describe their use
tags 591791 patch thanks Hi there, Attached is a tentative patch for this bug that documents what I think the requirements are both for alternative init systems in general, and for upstart in particular. Sorry this has taken so long; I spun my wheels on it for some time because I couldn't quite accept that there were so few additional requirements that needed to be specified here! I still don't entirely believe it, so please let me know if you see anything that I've overlooked. :) Also, it's possible that some of the bits I've marked as upstart-specific will also be applicable to systemd and should be moved up a section. I'm not familiar enough with the mechanics of systemd to say whether this is the case; eyeballs/wording tweaks welcome. 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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org From 9afbe359340924c87f19388925c93026c8711fe1 Mon Sep 17 00:00:00 2001 From: Steve Langasek vor...@debian.org Date: Sun, 9 Jan 2011 19:58:58 -0600 Subject: [PATCH] Document generic and upstart-specific init-system requirements Add a new section on alternative init systems that outlines the compatibility requirements for both init replacements and packages shipping upstart jobs. Closes: #591791 --- policy.sgml | 59 +++ 1 files changed, 59 insertions(+), 0 deletions(-) diff --git a/policy.sgml b/policy.sgml index 642f672..1c89ffe 100644 --- a/policy.sgml +++ b/policy.sgml @@ -6968,6 +6968,65 @@ Reloading vardescription/var configuration...done. /p /sect + sect id=alternateinit +headingAlternate init systems/heading +p + A number of other init systems are available now in Debian that + can be used in place of packagesysvinit/package. Alternative + init implementations must support running SysV init scripts as + described at ref id=sysvinit for compatibility. +/p +p + Packages may integrate with these replacement init systems by + providing implementation-specific configuration information about + how and when to start a service or in what order to run certain + tasks at boot time. However, any package integrating with other + init systems must also be backwards-compatible with + packagesysvinit/package by providing a SysV-style init script + with the same name as and equivalent functionality to any + init-specific job, as this is the only start-up configuration + method guaranteed to be supported by all init implementations. An + exception to this rule is scripts or jobs provided by the init + implementation itself; such jobs may be required for an + implementation-specific equivalent of the file/etc/rcS.d//file + scripts and may not have a one-to-one correspondence with the init + scripts. +/p +sect1 id=upstart + headingEvent-based boot with upstart/heading + + p +Packages may integrate with the prgnupstart/prgn event-based +boot system by installing job files in the +file/etc/init/file directory. SysV init scripts for which +an equivalent upstart job is available must query the output of +the command prgntelinit --version/prgn for the string +ttupstart/tt and avoid running in favor of the native +upstart job. + /p + p +Because packages shipping upstart jobs may be installed on +systems that are not using upstart, maintainer scripts must +still use the common prgnupdate-rc.d/prgn and +prgninvoke-rc.d/prgn interfaces for configuring runlevels +and for starting and stopping services. These maintainer +scripts must not call the prgnstart/prgn, +prgnrestart/prgn, prgnreload/prgn, or prgnstop/prgn +commands directly. Instead, implementations of +prgninvoke-rc.d/prgn must detect when upstart is running and +when an upstart job with the same name as an init script is +present, and perform the requested action using the upstart job +instead of the init script. + /p + p +Dependency-based boot managers for SysV init scripts, such as +packageinsserv/package, may bypass a given init script +entirely when an equivalent upstart job is present, to avoid +unnecessary forking of no-op init scripts. + /p + /sect1 + /sect + sect headingCron jobs/heading -- 1.7.1 signature.asc Description: Digital signature
Bug#591791: extend init.d policy to permit upstart jobs and describe their use
Package: debian-policy Severity: wishlist An action item from the upstart BoF today at DebConf is that policy language needs to be written around upstart jobs before we can start inflicting them on the archive. The following points should be addressed; they can be split into separate bug reports in the future if needed. - packages may ship upstart jobs under /etc/init - with limited exceptions (e.g., upstart itself!), a package that ships an upstart job must also ship a sysvinit init.d script that implements the same functionality - packages must use invoke-rc.d in maintainer scripts for either upstart jobs or init scripts (but invoke-rc.d must be modified first to support this) Patch to follow later :) -- 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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
