RFC - bootscript error reporting

James Robertson jwrober at linuxfromscratch.org
Thu Jan 29 08:38:13 PST 2004


Jeremy Utley wrote:
> On Wed, 2004-01-28 at 15:11, James Robertson wrote:
> 
>>I really like this.  As others have posted, not all errors are the same. 
>>  We would need to come up with some kind of system to trap errors from 
>>the different programs that are called within boot scritps.  Or if that 
>>is too hard, then at least some system to agree on a "criticality" of 
>>certain Sxx scripts.  Kxx scritps are important, but not as critical IMO 
>>as Sxx scripts when entering a certain rc level.
>>
>>Also, there needs to be a mechanism in place (in the bootscritps) to 
>>notify the administrator when he/she came back to the console that a 
>>reboot occured at such-and-such a date and time and what the result of 
>>any messages were.  This is especially important for the ones that get a 
>>timeout value and move on.  Can we use mail for that?  I don't know, I 
>>am not _that_ smart with Linux yet.
> 
> My thought was actually much simpler, but it can only be done after the
> system is in a read/write mode.  Have the bootscripts, as part of the
> boot process, write to /var/log/bootscripts.log, any failures or
> warnings that come about as part of the boot process.
> 
> Actually, now that I think about it...someone with more knowledge than
> me answer this - would it be possible to have a fifo device (via mkfifo)
> set up someplace where we could write messages to prior to the
> filesystem being mounted in r/w mode, then at S99log, cat the contents
> to that fifo into a log file?
> 

That seems like a good idea.  Also, can we take advantage of sysklogd?

>>On the simple pause idea, the time to pause needs to be easily 
>>changeable in a /etc/sysconfig file of some kind.  Everyone will have a 
>>different opinion as to how long they want the boot process to pause 
>>before continuing.
>
> Good idea - will definately file that one away for future reference!
> 
Kewl.
>><opinion>
>>I am also not sure that LFS needs to be concerned with headless or 
>>non-administrator-local machines.  I would love it in my production 
>>environment, but most of our readers reboot at the console.  The issues 
>>Jeremy brought up are more about that.  The easiest thing is simply to 
>>fix the scritps to support the enter key or change the text to say CRTL-J.
>>
>>I am only throwing this out for thought.  I actually would love to see 
>>Jeremy's idea put into the scripts.
>></opinion>
> 
> While in a lot of ways, I agree, James, there are a number of people who
> are actually using LFS-based systems in a production enviornment.  I
> know that I myself have gotten bit by this one on a number of occasions,
> and it's very annoying when you have to drive 45 minutes to the
> datacenter, or drag a NOC technician away from their TV long enough to
> punch the reset button.  One of the key advantages to Linux (at least
> for me) is the ability to remotely administer the machine, and making
> this change to LFS actually makes that possible.  

That is why I stuck it inside an opinion.  I was looking for a scope 
topic.  I also use LFS in a production data center, so I am on the same 
page as you on that.  The features you are looking for are awesome. 
Don't get me wrong.  I probably should not have even mentioned it at all 
as I want the same features you want and since you are writing the 
new/updated scripts, you can add those "enterprise" class features in. 
I know I will love the chance to test them out.  I just wanted to make 
sure we stayed in scope.  Looks like we are.

>I can see now we could
> actually integrate an option like this into your previous request, like
> so:
> 
> if [$PAUSE_DURATION == 0]
> then
>      read $i
> else
>      sleep $PAUSE_DURATION
> fi
> 
> 
> Comments?
> 

Yea, like it.


-- 
James Robertson -- jwrober at linuxfromscratch dot org
Reg. Linux User -- #160424 -- http://counter.li.org
Reg. LFS User   -- #6981   -- http://www.linuxfromscratch.org
LFS Bugzilla Maintainer    -- http://{blfs-}bugs.linuxfromscratch.org




More information about the lfs-dev mailing list