Fixing the network stop script

DJ Lucas dj at
Sat May 31 20:04:27 PDT 2003

Michael A. Peters wrote:
> On Wed, 2003-05-28 at 19:34, DJ Lucas wrote:
>>Consider this:  Move network to K45network (before sendsignals) so the 
>>network is down before sendsignals runs.
> No. Move sendsignals to the end - there is no reason to run sendsignals
> before the daemons themselves have had opportunity to bring themselves
> down.

True, but the netowrk script in LFS did not intend to support a client 
daemon for dhcp.

> I do it that way. I know Red Hat does it that way. I suspect many other
> distro's do as well.

Not exactly true.  Other distros, do place sendsignals furthur down the 
line.  However, BLFS places daemons that need to be brought down before 
it, appropriately at a lower number in the Stop scripts.  Other distros 
have a netfs script that does something similar to what I was planning 
above, while LFS/BLFS does not.  The network script as it is in the base 
LFS, is no different.  In it's default use, there is no reason not to 
run sendsignals before it.

You see, the problem is that sendsignals must be run before mountfs, 
else you have the potential of file locks, unclean fs's, and long 
timeouts durring a shutdown.  In addition to that, when networking comes 
into play, you have the possiblitly of having a major part of the OS 
being on a network volume.  Say that /usr is actually an NFS volume on 
some server, locked up in the server room, half way across campus.  You 
go to run the mountfs script, and because sendsignals has not yet been 
run, some random process still has a file open on /usr.  The unmount 
fails, and takes quite a bit of time doing it.  Now /usr definately is 
not cleanly unmounted when sendsignals runs and drops the network.  On 
top of that, we really don't want to mess with LFS's base bootscript 
order unless it is absolutely necessary.  This to avoid upgrade issues. 
  Moving the network script is somewhat trivial, but still undesireable, 
with the possible exception being on a case by case basis, and then only 
dealt with in the FAQ.

I agree that moving sendsignals to a later point in the bootscripts 
would give us a lot more room to work with, but that is not an option 
that I'd like to attempt to follow through with if it can be avoided. 
IMO, This issue is not important enough to warrant tyring to make a 
change in lfs-bootscripts, which might break the upgrade path for some 
not so savy users who don't quite understand the bootscripts.

Thanks for the feedback tho,


Unsubscribe: send email to listar at
and put 'unsubscribe blfs-dev' in the subject header of the message

More information about the blfs-dev mailing list