[lsb-discuss] install_initd clobbers system init symlinks

Thorsten Kukuk kukuk at suse.de
Mon Jul 14 06:42:17 PDT 2003

On Thu, Jul 10, Bart Whiteley wrote:

> I've just observed on SuSE that install_initd can move
> the boot order of some symlinks, even if install_initd was
> called to manage different services.  
> Example: I have an init script called foo.  I explicitly
> create the following symlinks:
> /etc/rc.d/rc3.d/S90foo  -> /etc/init.d/foo
> /etc/rc.d/rc4.d/S90foo  -> /etc/init.d/foo
> /etc/rc.d/rc5.d/S90foo  -> /etc/init.d/foo
> Then, I run install_initd for a different service.  Example:
>   /usr/lib/lsb/install_initd bar
> Now I have the following symlinks:
> /etc/rc.d/rc3.d/S09foo  -> ../foo
> /etc/rc.d/rc4.d/S09foo  -> ../foo
> /etc/rc.d/rc5.d/S09foo  -> ../foo
> Note that "90" was changed to "09", even though 
> I used install_initd on service foo, not bar.  
> This happens whether or not the foo script
> contains the INIT INFO data documented here:
> http://www.linuxbase.org/spec/refspecs/LSB_1.3.0/gLSB/gLSB/initscrcomconv.html
> Is this a SuSE bug, or the desired behavior for 
> install_initd?  

None of them. Our insserv (the tool which is called by install_initd)
reorders all symlinks to match the requirements of all scripts. Through
the Should-Start options, this ordering can change if you add a new
init script. If you add correct dependencies for your init script,
it should not matter if the ordering is changed or not, our script
should always work. Else fix the dependencies of the script.
> I think this is very bad.  If a sysadmin, through trial
> and error, finds the right boot order, and explicitly creates
> symlinks, they should not 
> be changed the next time an RPM postinstall script
> runs /usr/lib/lsb/install_initd.

It is not bad, this is a documented SuSE Linux/SLES 8 feature: You
should not create the symlinks at your own, instead you should use
insserv. Else SuSE Linux/SLES 8 will always renumber your symlinks
if you install/uninstall a RPM package with init scripts. This has
nothing to do with LSB.


Thorsten Kukuk       http://www.suse.de/~kukuk/        kukuk at suse.de
SuSE Linux AG        Deutschherrnstr. 15-19        D-90429 Nuernberg
Key fingerprint = A368 676B 5E1B 3E46 CFCE  2D97 F8FD 4E23 56C6 FB4B
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.linux-foundation.org/pipermail/lsb-discuss/attachments/20030714/2b15d67a/attachment.pgp 

More information about the lsb-discuss mailing list