Init script nightmare.

Paul Campbell paul at multimedia-campbell.com
Wed Nov 12 13:56:24 PST 2003


Gerard Beekmans wrote:
> You may blame me. In my defense: these are example scripts and not even
> meant for unattended boots. If you don't attend a boot, don't use the
> scripts. It really is as simple as that.

I just modified them a little to prevent stalls.  I am also moving sshd up
to the top of the list after network.

I had a problem with boot deps and msyslogd.  I tried to bring MySQL up
before it in the order...

network
mysql
msyslogd
portmap - mountd - nfs etc.
<HANG on exporting filesystems, or sometimes RPC.Mountd.>

I test booted a few times and it worked, until this morning.  Experimenting
when I got it to boot to single, and the order...

network
bind
mysql
mysyslogd
portmap .... nfs

seems to work (for now / this time / until the next time I NEED it up
immediately).  JIC anyone has the same prob.

> Having that said, I agree the bootscripts are in need for an overhaul.
> They are old and those 'read' statements seemed a good idea at the time,
> but I've since changed my mind about them. We just haven't gotten around
> fixing them up yet. It is planned to be done real soon and will appear
> on the Roadmap very soon too to fix in one of the upcoming 5.x releases.

Understood.  I would love to offer help, but I have offered help already to
alfs profile GUIs, and not had time yet, so I can't offer much more, would
be an empty promise.

A few ideas though.

Creating a temporary file to empty boot errors into during boot up, can be
controlled entirely from the functions and rc.  At the end a last rc init
script checks the log status and reports a Green Yellow Red status on the
boot.  Yellow or Red would invite you to read log, or STFU and get on with
it.

That way, the init scripts can fail and at the "end" there is a way to
validate the boot.  Complexities like "did the mail server come up",
"should I email my master about this", can be left for another time.

Gotta get back to compiling resuce disk....

Paul



More information about the lfs-support mailing list