On Thu, 24 Mar 2005 19:53:02 +0100, Edwin van Vliet <[EMAIL PROTECTED]> wrote:
> While installing LFS (development version) I have been reading the
> mailing lists, and repeatedly bumped into remarks which imply that LFS
> should be guided toward being an LSB compliant installation.

I have been suggesitng that the LFS project should move towards a LSB
compliant bootscript system, but nobody else has given me any
direction with this goal.  [I am going to try bringing it up again,
once BLFS 6.0 is done].



> Since I have recently installed a second LFS server (for testing and
> development), I just thought I might want to convert the existing
> bootscripts into LSB compatible ones. In fact, I have created a minimal
> set of scripts to boot the system, and for now it seems to work.
> 
> But I need a little feedback here. The LSB init functions for providing
> feedback to the end-user seem to be functions that provide this
> information *after* a process has started. It might not always be clear
> what the boot script is waiting for. Maybe you all can help find a
> solution for this. Let me describe what I have written so far:
>
> The /lib/lsb/init-functions provides some basic functionality as
> described in the LSB specification. For example:
> 
> log_failure_msg "Could not start process"
> 
> This results in the boot script echoing
> 
> [FAIL] Could not start process
> 
> With the word FAIL of course being red. But well, maybe someone else
> will want some other output, so what happens inside the "logging"
> functions might nog really be that important. But the (adjusted) scripts
> in /etc/init.d look like this:
> 
> command
> case "${?}" in
>     0) log_success_msg "Some success message" ;;
>     *) log_failure_msg "Some failure message" ;;
> esac
> 
> Well, if the command takes 10 seconds to complete, the bootscript is
> waiting, but the end user doesn't know what he's waiting for. Also, the
> command might create some output.

I saw this as well, but I dont know any other way to handle this problem.

> I have also adjusted the way the /etc/rc.d/rc*.d work, for example the
> /etc/rc.d/rc0.d contains the symlink 80-stop-network, pointing to
> ../../init.d/network. The /etc/rc.d/rc script calls /etc/init.d/network
> with the parameter "stop" so that the network is stopped at the right
> moment. This way, one could also create
> /etc/rc.d/rc3.d/20-restart-network so that the network is restarted if
> it is already active, or started if not, or
> /etc/rc.d/rc3.d/38-reload-httpd so that Apache is gracefully restarted.

I dont believe LSB mentions -reload- or -restart-.   If I recall, it
recommends sysv but does not make it required

> It would make the boot system more flexible. The old scripts could only
> start or kill processes. The LSB specification imply this can be
> improved a bit.
> 
> More questions: the LSB specifications mention "facilities" like
> $local_fs and $network, but is not very clear on the implementation of
> it all. I have therefore just created /etc/init.d/local_fs and
> /etc/init.d/network as I think that the install_initd scripts should
> provide any implementation logic (and should therefore be included with
> the LSB compliant package). Also: if the /etc/init.d scripts themselves
> include their own requirements, the install_initd script should probably
>   automatically create the symbolic links and should make sure the
> scripts are called in the correct order. This problem can be resolved
> later on.

I dont know what it means by this either, but I think the $ is part of
the filename...  Perhaps the status lines are called to find out if a
service is running or not.

> I apologize for the incoherent post, as I'm still brainstorming on this
> subject, and any feedback might provide quite useful.
> 
> Last but not least: should this be a LFS package, of should such a
> package be a small project on it's own?

I started work on a lsb compliant functions file in the bootscripts [I
think some of the return codes are wrong], if you wish to see what we
have so far.

-- 
Nathan Coulson (conathan)
------
nathan at linuxfromscratch org
conathan at gmail com
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Reply via email to