Date: Tue, 21 Feb 2006 13:25:42 -0800 From: "Kevin Oberman" <oberman@es.net> To: Tobias Roth <roth@iam.unibe.ch> Cc: freebsd-rc@freebsd.org Subject: Re: dhclient existing when run early in startup Message-ID: <20060221212542.A5E4645048@ptavv.es.net> In-Reply-To: Your message of "Tue, 21 Feb 2006 08:51:40 %2B0100." <20060221075140.GA9101@droopy.unibe.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
> Date: Tue, 21 Feb 2006 08:51:40 +0100 > From: Tobias Roth <roth@iam.unibe.ch> > > 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 just tried the latest. dhclient still fails on current. the problem is in dhclient.c at about line 407 where it checks for chroot. For this to work, you must either have defined _PATH_VAREMPTY to your chrooted environment or have /var/empty on your system. What I plan on doing later today is to restore the mdmfs stuff and create a /tmp/empty and define _PATH_VAREMPTY to point at it in lieu of /var/empty. > > > 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 am seeing a problem when I run dhclient twice, even though the first has been killed. I suspect it may be because the leases file from the profile run has been lost. It may be required to put the leases file from that operation somewhere that is not volatile. Within my time constraints, I'm happy to debug, too. > > 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? Actually, I don't as only root is mounted. /var is simply a directory on / at the time profile runs. Since / is now mounted rw, I can write into /var (or /tmp) with no problems. I just have to make sure to clean up as some root partitions are pretty tight on space. (Not a problem for me, though.) I am still mulling the pros and cons of a malloc'ed md and I think I've decided to go back to it as it does resolve the clean-up issue very nicely. It may not be needed with AFTER: root, but it looks like the "right" answer. > > 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. And profile, while not as easy to use as Windows zero config, is WAY, WAY more flexible. > Thanks, Tobias > > P.S. should we move this discussion to freebsd-rc? Done.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060221212542.A5E4645048>