Re: dhclient existing when run early in startup

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.

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 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?

> 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.

> 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
2) store the lease somewhere on /, now that it is rw

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.

Thanks, Tobias

P.S. should we move this discussion to freebsd-rc?