[Fedora-packaging] LSB initscript ordering issues

John Dennis jdennis at redhat.com
Thu Dec 3 15:33:23 UTC 2009

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:

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 at redhat.com>

Looking to carve out IT costs?

More information about the Fedora-packaging mailing list