dhclient existing when run early in startup

[Brooks Davis]

[Moved to freebsd-rc]

On Tue, Feb 21, 2006 at 08:51:40AM +0100, Tobias Roth wrote:
> On Mon, Feb 20, 2006 at 08:53:24PM -0800, Kevin Oberman wrote:
> > > On Mon, Feb 20, 2006 at 05:20:29PM -0800, Kevin Oberman wrote:
> > > > I have a script (Tobias Roth's profile) that runs right after root is
> > > > mounted r/w. With the new OpenBSD dhclient, it fails completely. If I
> > > > run it later (after the system is up), it works fine.
> > > > 
> > > > The only messages I get are:
> > > > chroot
> > > > exit;
> > > > 
> > > > Any idea what is causing this and if there is a work-around other than
> > > > ISC dhclient?
> 
> Kevin: Did you try the latest version? DHCP works fine here with rev25,
> which is the second latest available. The latest has the REQUIRE and
> BEFORE lines changed as you suggested, to allow fscking again.
> 
> > > I really don't have any idea where to start debugging this.  Can you
> > > verify that profile runs before netif?  If it doesn't, profile is
> > > probably messing with the interface in an unsupported way and killing
> > > dhclient.  With the base doing a better job of supporting dynamic
> > > configuration, we're diverging more and more from the 4.x model profile
> > > is based on so it's going to be increasingly difficult to make it work
> > > without major rewrites.
> 
> Brooks: I'm happy to debug, since the problem is obviously with profile and
> not with dhclient. Yes, dhclient is killed for the following reason: After
> a profile that requires dhcp has been tested for, the script attempts to
> restore the system context to how it usually is at this point in the rc.d/
> chain. So since profile runs between root and mountcritlocal, dhclient
> is killed. The next three things that can happen are the check for the
> next profile (which may or may not require dhcp), the selection of the
> current profile (in that case, the dhclient kill may be not needed, as it
> will run later in the rc.d/ chain again) or the usage of the default
> profile (i.e. no union mounts over /etc, there again dhclient may or may
> not be needed again later).
>  
> How would you attempt to handle this situation, if killing dhclient is
> not permitted/desired? Do you have other critique or ideas about profile,
> how to improve it? I still think its way of handling the whole 'laptop
> multihoming' problem is the most flexible, and I also think with some
> more work it can be made ready for a trial in -CURRENT. Please let me
> know if you disagree.

To be honest, I don't see anything profile.sh is doing that should cause
a problem for dhclient other than running it way too early so long as
/etc/rc.d/netif is run correctly which it looks like should be the case.
That may change in the future as I'm planning to more to an even more
dynamic dhclient configuration for 7.0 where by default it isn't run
except when the link comes up and the kernel signals devd.

> The only other way of handling 'laptop multihoming' I see is to create
> a program that specifically handles all the testing, and put it into
> /sbin. But even then, I think using union mounts is the way to go. I'd
> be glad to discuss this more deeply.

I think a seperate probing program might be worthwhile.  I think jwd's
variant symlink support might make a cleaner solution since it would
eliminate the need for the union mounts and much of the maintance
headache involved in fixing the default files

> > I should have spent a bit longer looking at the sources before posting
> > the question.  Sorry.
> > 
> > I think I've got it, but I won't be able to test it until tomorrow.
> > 
> > profile.sh wants to run as early as possible as it allows you to pick a
> > different set of files in /etc depending on where you are. It runs after
> > root and before mountcritlocal. If you run a startup script before
> > mountcritlocal, you don't have /var/empty and the chroot(_PATH_VAREMPTY)
> > fails, printing out the less than useful "chroot" message. 
> 
> Kevin: So you probably have / and /var on different partitions, and
> that is what breaks profile. I'll look into this, it must be fixed.
> Can you confirm that this might be the cause of the problem?

FWIW, just creating a /var/empty on / and leaving it there would be
pretty harmless.  It would waste one whole inode. :)

> > BTW, profile was originally written for V5 as it needs RCng to do many
> > of its things for suspend and resume. (I am not positive that Tobias
> > didn't have a V4 version of it, but I don't think so and the code would
> > have had be have been almost totally re-written.)
> 
> There never was a V4 version.

Sorry, that was a misrecollection on my part. :(

> > profile.sh runs when there is really not much system to work with. I
> > modified the script to create /var/empty and then clean it up. It
> > already creates a config file in /var and specifies that the lease file
> > goes into /var, as well. (Of course, at this point /var is just a
> > directory; not a mountpoint.)
> 
> What actually happens is that a temporary memory filesystem is created and 
> placed over /tmp. There are two reasons for this. The first one is still
> valid: The default timeout for dhclient is 60s, which is way too long
> for a profile check. Since the timeout cannot be specified on the
> commandline, a config file that lowers the timeout has to be created and
> stored somewhere. The second reason is that earlier versions of profile
> where executed before root, and thus had no place to save temporary files.
> So the temporary memory file system was a hack to get a place to store
> both the lease and the config file for the duration of the dhcp test. The
> isc version of dhclient also wanted to store a pid file somewhere.
> 
> Possible improvements:
> 1) change dhclient to accept a timeout on the commandline

This would be a useful addon.  Actually, I'd like to see both the option
to specify a shorter one and the option to keep trying forever since
that's what's wanted in some scenerios.

> 2) store the lease somewhere on /, now that it is rw

Unless profile were moved to after cleanvar you'll need to shutdown
dhclient and start it back up again later.

> I would really like to make profile more useful and bring it to a state
> where people don't think about it as 'just some ugly hack'. The problem
> it tackles is one that pretty much every laptop owner has, and there is
> much demand for a clean solution.

I like the idea of being able to configure things based on your
location.  I'm not sure about profile's model of mobility.  With the new
dhclient and the change to triggering on link state events we're moving
to a much more dynamic model of interface management.  From my read of
profile.sh, the model you are using appears to be that the device's
location only really changes when the laptop is either off or
suspended.  By contrast, we've been assuming that the network can change
at any time without warning.  We also don't assume the same interface
will be used over time.  I don't think the two models are totally
incompatable, but there are likely to be some rough edges in various
places.

-- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-rc/attachments/20060221/188cd61a/attachment.bin