Using the LSB Bootscripts

Jeremy Huntwork jhuntwork at
Sun May 8 17:57:25 PDT 2011

On 5/8/11 8:46 PM, Bryan Kadzban wrote:
> This seems like it might be starting to get complicated.  The scripts
> may set up more than just IP addresses.  (I have one to set up WoL bits
> via ethtool, for instance.)
> I don't think there's any way to make all potential service scripts able
> to handle switching to and from all the other potential service scripts,
> just by starting them.  I don't think that means it's not worth trying
> to do this, but we do have to be careful not to imply that this sort of
> thing will always work.

Well, how many services will there ever be that operate on the same 
device? If there's much more than what I'm thinking, perhaps you're 
right and it is complicated. In which case I think the underlying 
methodology for bringing up the device needs to be adjusted somehow. 
Bringing up the device by configuration is fine - that's how it should 
be. When taking it down, however, you need to remove any possible 
configured service on it.

> I do think putting the service scripts under a subdirectory /lib is
> good, but maybe /lib/network-services or something (to be more explicit)
> would be better than plain "services".

Yes, I almost did this. It looked a bit long, but it was explicit. I 
could go either way here.

> I don't like it (not yet anyway :-) ).  I find "sysconfig" to be a *far*
> more descriptive name than "default".
> (Also I associate "default" with Ubuntu, which does not bring up happy
> thoughts.  The reasons are not exactly important, and this is obviously
> a personal-opinion thing.  And I now know it's at least a Debian thing,
> and might be more widespread.  But the first impression still exists.)

The reason default was chosen was in order to merge other system-wide 
configuration files, such as /etc/default/useradd, for example. Either 
name works for me, really, but the idea was to consolidate.

> The only times I restart sshd, it happens from an ssh session.  I think
> this needs to continue working.  You said (later on) that this only
> applies to halting the system, but doesn't "reload" just call "stop" and
> then "start", and doesn't system-halt just call "stop"?
> It may be possible to do as you describe, but I'm not sure how; I'd like
> to see how it was done.  :-)

I'll get the scripts up as soon as I can. I had to take a break to 
finish up some other important work tonight. At the latest, I'll have 
them available tomorrow.


More information about the lfs-dev mailing list