[lsb-discuss] install_initd clobbers system init symlinks

Bart Whiteley bwhiteley at novell.com
Mon Jul 14 08:34:22 PDT 2003


I've talked to several IS&T people, and they all agree that
this is evil.  

For instance, my application requires another third party 
application (that I have no control over) to be started 
before mine is started.  This other third party app doesn't 
have LSB style comments in its init script.  Therefore it 
"provides" nothing, so I can't require it to be started.  

Once again, if a sysadmin finds a problem with the boot
order, and explicitly fixes it, you SHOULD NOT change it 
the next time a package is installed that calls insserv. 
Or, at the very least there should be some documented
way to make it "sticky" or something, so when the reordering
occurs it skips the "sticky" ones. 

Luckily, I've found a way around the insserv script bug. 
I discovered that the symlinks for the other third party app
didn't get changed by insserv.  I observed that this was 
because they used all upper-case letters in the name of 
their symlink, and lower-case in the actual script name.  This
achieves the "stickiness" described above.  I did the same
with my app, and it is happy now.  

If I hadn't stumbled on to this, we would be broken on SuSE, 
with no know way to fix it other than to tell users to manually
inspect/fix their symlinks after every system update -- ouch. 

insserv is not an option.  install_initrd might someday 
be an option.  Currently, if you want your app to run on 
multiple distros, explicitly creating symlinks in postinstall
is the best way to go.  I've tried if, elif statements in postinstall
scripts that check for insserv, then chkconfig, ...   I always
encounter problems and go back to explicitly creating
symlinks.  Until LSB is more ubiquitous, this is the only way
to go. 

On Monday 14 July 2003 07:42 am, Thorsten Kukuk wrote:
> 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

-- 
Bart Whiteley <bwhiteley at novell.com>
Novell, Inc., the leading provider of information solutions
http://www.novell.com/





More information about the lsb-discuss mailing list