On Thu, Jan 24, 2013 at 7:03 AM, Stroller <strol...@stellar.eclipse.co.uk> wrote: > I think, to be rigorous, I would want to test this system (I'm not saying you > should keep it this way) by setting the IP address statically for eth1. > > From what I'm understanding, this doesn't sound like a MySQL problem, but a > DHCP problem.
You're correct. When I set the interface statically, MySQL starts up like a champ. > You're checking the IP address with ifconfig - I believe that is deprecated. > I guess at some point you might replace that in your `echo > test.log` > scripts with the newer tools, just to make sure they say the same thing. > Maybe this is paranoia, but you know what they say about that. > > http://blog.timheckman.net/2011/12/22/why-you-should-replace-ifconfig/ Thanks for the link. I'll definitely check that out. >> ... >> eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 >> inet6 NNNN:NNNN:NNNN:NNNN:NNNN:NNNN:NNNN:NNNN prefixlen 64 >> scopeid 0x0<global> >> inet6 NNNN::NNNN:NNNN:NNNN:NNNN prefixlen 64 scopeid 0x20<link> > > I don't think these are valid IPv6 addresses. If you're not using IPv6 then I > would recommend removing the IPv6 USE flag globally and remerging everything > --newuse. This will ensure nothing is depending upon IPv6 or expecting it or > waiting for it. The real addresses are valid, I just didn't want to put them in a public mailing list message so I edited them. IPv6 on my network (through a Hurricane Electric tunnel) is working fine. >> The entries for eth1 in /etc/conf.d/net are: >> >> config_eth1="dhcp" >> routes_eth1="239.0.0.0/8" > > Is this right? Yes. The extra route is so that DLNA/uPnP works correctly on my network. >> I could add a delay to the mysql script to ensure startup, but I'd >> rather figure out why the IP address is not yet available even though >> the net.eth1 script has completed. Does anyone have any hints on what >> could be going wrong? > > There are several DHCP clients available in Portage. > > You need to tell us which one you're using. I did, although it was sort of hidden in the list of upgraded packages: "dhcpcd was upgraded from 5.2.12 to 5.6.4". > It wouldn't do any harm to experiment with one or two others. > > I think that a busybox version may be installed on some systems, and that > this may interfere or misbehave. I don't know if a bug report has been filed > for this.6 In any case, I did some more debugging and found that the problem seems to be an interaction between dhcpcd and IPv6 configuration. The latest version of dhcpcd now attempts by default to take over IPv6 stateless configuration instead of letting the kernel take care of it as happened before. dhcpcd appears to be getting an IPv6 address set up before the IPv4 configuration is complete, and considers this "good enough" to background itself instead of waiting for the IPv4 configuration to be complete. The workaround was to add "noipv6rs" (Disable solicition of IPv6 Router Advertisements) to the /etc/dhcpcd.conf file so that dhcpcd ignores IPv6 configuration. The kernel still configures IPv6 correctly, and dhcpcd now waits for the IPv4 configuration to be complete before backgrounding itself. -- Manuel A. McLure WW1FA <man...@mclure.org> <http://www.mclure.org> ...for in Ulthar, according to an ancient and significant law, no man may kill a cat. -- H.P. Lovecraft
