Summary: Using the LSB Bootscripts

Bryan Kadzban bryan at
Sun May 15 22:49:44 PDT 2011

Zachary Kotlarek wrote:
> On May 15, 2011, at 12:31 PM, Bryan Kadzban wrote:
>> I'm trying to figure out why it'd be necessary to do this.  We 
>> already have the previous configuration of every interface stuffed 
>> away in /run, and we use that when deciding which service scripts 
>> to call when bringing down networking.  Doesn't that kill the pppd 
>> / pppoe / dhclient / dhcpcd / whatever daemons already?  And 
>> doesn't that remove the IPs that were configured already, for 
>> static?
> I thought the goal was to predictably handle scenarios where the 
> running config didn't match the cached version, or where there was no
> cached version.

While I don't want to speak for the people actually doing the work here,
it seems to me like this might be getting a bit complicated for the wins
here.  I don't think it's very likely that there is no cached version
(since we store it away at boot time when the scripts set up the

I also *think* the only way the cached config might not match the
running config is if root mucked with the running config manually.  And
in that case, I don't think it's smart to override that decision.

(Consider, for instance, a setup that requires two IPs on a single NIC,
both on a single subnet -- say one for management and another for real
traffic, with filtering upstream to prevent management packets from the
public Internet.  The management IP might be set up outside the scripts
for some reason (especially at machine setup time, but potentially in
other cases as well, for configuration management and redundancy
reasons), in which case flushing all IPs at interface-down would be
actively harmful.)

Though I suppose this isn't terribly likely either.  Hmm.

> If the goal is only to directly cancel the configuration as-cached, 
> and not to care if that cache is no longer accurate or no longer 
> exists, then I agree, there's no need to do any of this special 
> handling as the normal service scripts should be sufficient.

I'm not sure what the goal *should* be.  :-)  Does it make sense to try
to clean up completely in this kind of setup?  Maybe or maybe not.

I do think it's least *surprising* to only undo the effects of the start
script, though.  For whatever that's worth.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the lfs-dev mailing list