I'm in the process of cleaning up an initscript I own to meet LSB standards but this has left me with several questions primarilary in the area of start up ordering.
FYI, I'm utilizing the guidelines found here: https://fedoraproject.org/wiki/FCNewInit/Initscripts https://fedoraproject.org/wiki/Packaging/SysVInitScript
In the past we used hardcoded chkconfig start/stop numbers to control the order in which services were started and stopped. My understanding is that is deprecated (although still supported) but the preferred method is the LSB boot facility declarations (Required-Start, Should-Start, Required-Stop, Should-Stop). Correct?
The section describing facility names seems a bit vague to me:
Shouldn't the guidelines *require* that the LSB block have a Provides: declaration which at a minimum includes a name matching the initscript? If you read between the lines the guidelines seem to suggest that but it's not clearly an explicit mandate. Without that I don't see how one can use the boot facility dependencies for other services. In other words if I depend on mysql running then mysql must have declared it provides mysql, or is that provides implicit as opposed to explicit?
In addition to the explicit eponymous Provides: what about virtual provides? Do we have a set of virtual provide names? (e.g. mailserver, webserver, or ldapserver)
The guidelines also state that an initiscript should never be marked as %config and instead import configuration settings from /etc/sysconfig/$name. But what about the case where a service may have a variety of boot dependencies depending on how it's configured? For example a service might be configured to optionally use mysql vs. postgres, or to use LDAP vs. SQL so it will have boot dependencies on particular services which cannot be hardwired ahead of time. I doubt the LSB block parsing logic handles "includes" from /etc/sysconfig, or does it? Assuming not then the initscript has to be marked as %config right?
John Dennis (jdennis@redhat.com) said:
In the past we used hardcoded chkconfig start/stop numbers to control the order in which services were started and stopped. My understanding is that is deprecated (although still supported) but the preferred method is the LSB boot facility declarations (Required-Start, Should-Start, Required-Stop, Should-Stop). Correct?
I wouldn't say it's *preferred*. It's an alternate method.
The section describing facility names seems a bit vague to me:
Shouldn't the guidelines *require* that the LSB block have a Provides: declaration which at a minimum includes a name matching the initscript?
That's implicitly provided no matter what.
In addition to the explicit eponymous Provides: what about virtual provides? Do we have a set of virtual provide names? (e.g. mailserver, webserver, or ldapserver)
No. Those aren't defined in the spec.
The guidelines also state that an initiscript should never be marked as %config and instead import configuration settings from /etc/sysconfig/$name. But what about the case where a service may have a variety of boot dependencies depending on how it's configured? For example a service might be configured to optionally use mysql vs. postgres, or to use LDAP vs. SQL so it will have boot dependencies on particular services which cannot be hardwired ahead of time.
The LSB spec won't help you here, alas.
I doubt the LSB block parsing logic handles "includes" from /etc/sysconfig, or does it?
It does not.
Bill
On 12/03/2009 10:39 AM, Bill Nottingham wrote:
John Dennis (jdennis@redhat.com) said:
In the past we used hardcoded chkconfig start/stop numbers to control the order in which services were started and stopped. My understanding is that is deprecated (although still supported) but the preferred method is the LSB boot facility declarations (Required-Start, Should-Start, Required-Stop, Should-Stop). Correct?
I wouldn't say it's *preferred*. It's an alternate method.
The section describing facility names seems a bit vague to me:
Shouldn't the guidelines *require* that the LSB block have a Provides: declaration which at a minimum includes a name matching the initscript?
That's implicitly provided no matter what.
It might be nice to update the wiki to make this clear.
In addition to the explicit eponymous Provides: what about virtual provides? Do we have a set of virtual provide names? (e.g. mailserver, webserver, or ldapserver)
No. Those aren't defined in the spec.
Right, it's not an LSB issue but a Fedora packaging issue. Do we intend to define such a set of virtual provides for Fedora?
The guidelines also state that an initiscript should never be marked as %config and instead import configuration settings from /etc/sysconfig/$name. But what about the case where a service may have a variety of boot dependencies depending on how it's configured? For example a service might be configured to optionally use mysql vs. postgres, or to use LDAP vs. SQL so it will have boot dependencies on particular services which cannot be hardwired ahead of time.
The LSB spec won't help you here, alas.
Right, this isn't an LSB spec issue but a Fedora packaging guideline issue. If a sysadmin configures the service to depend on a specific set of dependency services then he/she will have to edit the initscript, thus it should be marked %config so that this customization is not lost.
I doubt the LSB block parsing logic handles "includes" from /etc/sysconfig, or does it?
It does not.
Bill
On Thu, Dec 03, 2009 at 10:48:04AM -0500, John Dennis wrote:
On 12/03/2009 10:39 AM, Bill Nottingham wrote:
John Dennis (jdennis@redhat.com) said:
In the past we used hardcoded chkconfig start/stop numbers to control the order in which services were started and stopped. My understanding is that is deprecated (although still supported) but the preferred method is the LSB boot facility declarations (Required-Start, Should-Start, Required-Stop, Should-Stop). Correct?
I wouldn't say it's *preferred*. It's an alternate method.
The section describing facility names seems a bit vague to me:
Shouldn't the guidelines *require* that the LSB block have a Provides: declaration which at a minimum includes a name matching the initscript?
That's implicitly provided no matter what.
It might be nice to update the wiki to make this clear.
The Guidelines actually did require this. I've updated it to reflect that the service name is implicitly noted.
In addition to the explicit eponymous Provides: what about virtual provides? Do we have a set of virtual provide names? (e.g. mailserver, webserver, or ldapserver)
No. Those aren't defined in the spec.
Right, it's not an LSB issue but a Fedora packaging issue. Do we intend to define such a set of virtual provides for Fedora?
This would make sense. If you could propose a list to add that would be great. You might want to work with the virtual provides for services within rpms, at least to use the same names, even if we don't end up using both.
The guidelines also state that an initiscript should never be marked as %config and instead import configuration settings from /etc/sysconfig/$name. But what about the case where a service may have a variety of boot dependencies depending on how it's configured? For example a service might be configured to optionally use mysql vs. postgres, or to use LDAP vs. SQL so it will have boot dependencies on particular services which cannot be hardwired ahead of time.
The LSB spec won't help you here, alas.
Right, this isn't an LSB spec issue but a Fedora packaging guideline issue. If a sysadmin configures the service to depend on a specific set of dependency services then he/she will have to edit the initscript, thus it should be marked %config so that this customization is not lost.
It could be that the LSB, dependency style is not flexible enough to work in this instance. We might be able to work around this with virtual provides, though. We do want to avoid marking init scripts as %config and eventually, in the indefinite sense, we can use upstart's facilities to do this sort of thing. So I'm not certain that we'd want to start encouraging people to mix config with the initscripts yet.
-Toshio
On 12/03/2009 02:55 PM, Toshio Kuratomi wrote:
On Thu, Dec 03, 2009 at 10:48:04AM -0500, John Dennis wrote:
On 12/03/2009 10:39 AM, Bill Nottingham wrote:
John Dennis (jdennis@redhat.com) said:
The guidelines also state that an initiscript should never be marked as %config and instead import configuration settings from /etc/sysconfig/$name. But what about the case where a service may have a variety of boot dependencies depending on how it's configured? For example a service might be configured to optionally use mysql vs. postgres, or to use LDAP vs. SQL so it will have boot dependencies on particular services which cannot be hardwired ahead of time.
The LSB spec won't help you here, alas.
Right, this isn't an LSB spec issue but a Fedora packaging guideline issue. If a sysadmin configures the service to depend on a specific set of dependency services then he/she will have to edit the initscript, thus it should be marked %config so that this customization is not lost.
It could be that the LSB, dependency style is not flexible enough to work in this instance. We might be able to work around this with virtual provides, though. We do want to avoid marking init scripts as %config and eventually, in the indefinite sense, we can use upstart's facilities to do this sort of thing. So I'm not certain that we'd want to start encouraging people to mix config with the initscripts yet.
A more careful reading of the LSB spec might indicate this is a moot issue after all. If I understand correctly I think this can be accomplished by listing *every* optional dependency in the Should-Start list.
If I'm reading it correctly the items in Should-Start will be started earlier if and only if they are enabled to start.
For example if you're dependent on a SQL database and can choose between mysql and postgres in your configuration and elect to use mysql. Then the initscript would have:
# Should-Start: mysql postgres
and all the sysadmin must do is enable mysql to start at boot. Because mysql is enabled the mysql dependency will be honored, but the postgres dependency will not be honored because it's not enabled.
Or at least that's my interpretation ...
John Dennis (jdennis@redhat.com) said:
It could be that the LSB, dependency style is not flexible enough to work in this instance. We might be able to work around this with virtual provides, though. We do want to avoid marking init scripts as %config and eventually, in the indefinite sense, we can use upstart's facilities to do this sort of thing. So I'm not certain that we'd want to start encouraging people to mix config with the initscripts yet.
A more careful reading of the LSB spec might indicate this is a moot issue after all. If I understand correctly I think this can be accomplished by listing *every* optional dependency in the Should-Start list.
If I'm reading it correctly the items in Should-Start will be started earlier if and only if they are enabled to start.
For example if you're dependent on a SQL database and can choose between mysql and postgres in your configuration and elect to use mysql. Then the initscript would have:
# Should-Start: mysql postgres
and all the sysadmin must do is enable mysql to start at boot. Because mysql is enabled the mysql dependency will be honored, but the postgres dependency will not be honored because it's not enabled.
Alas, not until I (or someone) gets around to fixing https://bugzilla.redhat.com/show_bug.cgi?id=98470
Should-Start is listed as optional in the spec, FWIW.
Bill
On Thu, 03 Dec 2009 10:33:23 -0500 John Dennis jdennis@redhat.com wrote:
I'm in the process of cleaning up an initscript I own to meet LSB standards but this has left me with several questions primarilary in the area of start up ordering.
FYI, I'm utilizing the guidelines found here: https://fedoraproject.org/wiki/FCNewInit/Initscripts
...snip...
Just so it's clear: the above link is NOT a guideline... only the other link (https://fedoraproject.org/wiki/Packaging/SysVInitScript) is.
I have updated the page to note that it's not a guideline.
kevin
packaging@lists.fedoraproject.org
-
Bill Nottingham -
John Dennis -
Kevin Fenzi -
Toshio Kuratomi