[00:07] aha I have found cjwatson at last ;) [00:09] antarus: hmm? [00:11] cjwatson: I am testing a patch to netcfg; I think the precise version has a bug [00:12] https://bugs.launchpad.net/ubuntu/+source/netcfg/+bug/917905, fyi [00:12] Launchpad bug 917905 in netcfg "netcfg hang bug in autoconfig.c" [Undecided,Confirmed] [00:17] antarus: it seems odd that it would hang on the fgets call; shouldn't that get EOF instead? [00:18] cjwatson: dhclient never exits [00:18] so it wouldn't get SIGPIPE or EOF [00:19] on my network dhclient just retries forever [00:19] ah, annoying thing that you have to kill, right - there's some discrepancy among the different clients here [00:20] yeah its a mess :/ [00:20] (you wouldn't get SIGPIPE anyway; that's for writes, not reads) [00:20] my patch basically checks rv, and if we didn't get a lease, doesn't bother reading from the pipe at all [00:20] although I think it also breaks the 'retry' logic [00:21] I think it exits quickly with stateless autoconfig but not stateful [00:21] I'm a bit worried about that because 0 returned from poll_dhcpv6_client is documented as "not known to have acquired a lease" [00:21] rather than definitely not [00:22] I wonder if it would be better to arrange for dhclient to actually exit [00:22] dhclient does support a timeout option afaik [00:22] so we could push the preseed config value down to it? [00:22] I'm concerned that if we don't read from the pipe on failure, there are cases where we'll end up with a stuck client for one reason or another [00:24] passing down the timeout would be fine; it's documented as 300 seconds by default [00:25] I think that would be worth a go [00:29] bleh, the dhclient binary in the initrd doesn't support -timeout ? [00:30] nor does any ISC dhclient binary that I know of; it goes in the configuration file [00:41] cjwatson: the timeout only works if I pass -1 to dhclient (to exit if it failed to get a lease) [00:42] cjwatson: otherwise it will combine timeout + retry + backoff and just retry forever apparently [00:45] which means it will only try once rather than retrying a few times, right? [00:45] correct [00:46] well for me I set the timeout to 5s, and it tried 4-5 times and then gave up [00:46] ahh, it did 3 attempts until it hit my 5s timeout and then quit [00:47] I'm just unclear because another segment talks about keepign the client alive and having the user request we 'retry' [00:47] and I'm not clear how the retry logic is supposed to work [00:47] * This function will NOT kill the child if time runs out. This allows [00:47] * the user to choose to wait longer for the lease to be acquired. [00:48] that comment basically [00:49] That may be a dead comment [00:49] I can't see how you'd do that - you'd select "Retry network autoconfiguration" which would start a new client [00:50] ok, I will go ahead and push the netcfg/dhcpv6_timeout into the dhclient config file and pass it '-1' so it will oneshot attempt. Does that sound reasonable to you? [00:51] (The history of this branch is that one developer did about 90% of the work and then quit, and I picked it up and bodged it into shape with some help from stgraber; so I can't be authoritative on all of it) [00:51] I think it's worth a go. stgraber has a scary test suite he should be able to run it through [00:51] excellent [00:51] I like test suites :) [00:58] which reminds me I really need to get the tests running daily on Precise... [02:12] cjwatson: excellent, my patch works here (after much futzing with initrds) [04:31] bah [04:31] my initrd has a different bug now [04:31] * antarus will finish this tomorrow [05:18] stgraber: sure no problem. === mdeslaur is now known as mdeslaur_ === mdeslaur_ is now known as mdeslaur [19:16] cjwatson: is there some way to run netcfg in debug mode? [19:16] DEBCONF_DEBUG=developer on the kernel command line will show a trace of all debconf interaction, and watch syslog [19:16] not really beyond that [19:17] ok [19:17] my patch seems to have fixed the ipv6 issue, but not it won't autodetect my hardware [19:18] and I can't really see how the two are related [19:19] that isn't generally even netcfg's responsibility [19:20] compare the rest of your initrd with the stock one [19:24] hrm, ptom differs for some reason [19:26] oh its a symlink to netcfg [19:26] heh [19:26] * antarus makes a new initrd anyway [19:29] ahh looks like I had an old copy [19:35] cjwatson: excellent, works with a new initrd ;) [19:49] good good