after baselayout 1.12.x update mysql daemon tries to start before net.lo so it fails. I added in /etc/init.d/net.lo the line: before mysql And now it starts fine.... Reproducible: Always Steps to Reproduce: 1.emerge baselayout-1.12.x 2. 3. Actual Results: mysql daemon failed to start at boot time. Expected Results: mysql should start after the net.lo initialization
move mysql from the boot runlevel to the default runlevel
mysql IS at the default level net.lo IS at boot level. but after the baselayout update net.lo was loading towards the end of the boot process even if it was at boot level
post the output of `rc-config list`
This happend to me too with some other packages from time to time. Kernel version or netdrivers as modules seemed to have a effect on it, not sure if it does in your case.
Available init scripts alsasound boot apache2 bootmisc boot checkfs boot checkroot boot clock boot coldplug default consolefont boot courier-authlib courier-imapd courier-imapd-ssl courier-pop3d default courier-pop3d-ssl cpudyn cpufreqd cpufrequtils crypto-loop cupsd default ddclient default domainname default esound famd fancontrol default firestarter gkrellmd gpm hdparm default hostname boot default hotplug ip6tables iptables keymaps boot lisa lm_sensors default local default nonetwork localmount boot metalog default mldonkey modules boot mysql default net.eth0 default net.lo boot netmount default nscd ntp-client ntpd default numlock portmap powernowd pwcheck reslisa rmnologin boot rsyncd samba saslauthd serial boot smartd default spamd sshd default svnserve svscan default urandom boot vixie-cron xdm xfs
I have encountered this issue too, currently using sys-apps/baselayout-1.12.0_pre8-r1 with net.lo in the boot runlevel and lo was started just before local at the very end. I have mysql in the default run level also. This is on an amd64 machine if that makes any difference at all.
Does mysql start before you enter runlevel 3? Does net.lo end before you enter runlevel 3?
mysql starts in runlevel 3 as expected. Like I said before it is net.lo which doesn't start until right at the end of runlevel 3 just before local starts and you get the login prompt.
What's the value of RC_STRICT_NET_CHECKING in /etc/conf.d/rc?
I have RC_NET_STRICT_CHECKING="no" which I believe was the default as set. This still means that lo should be brought up first doesn't it?
I have also RC_STRICT_NET_CHECKING set to no. But this was the default. maybe a change to yes, will help?
Try setting RC_PARALLEL_STARTUP="yes". Although it seems 100% unrelated to the issue at hand, it has cured this problem for one user.
the last time I found about RC_PARALLEL_STARTUP and set it to "yes" A lot o things (daemon) didn't like my decision. It meshed up a lot of things.
We recently fixes a lot of parallel startup isses, why not try it again and see if it helps this issue? If parallel causes issues (but not related to this bug) then please open a new bug. Thanks
Yes, but it will be a 'workaround' not a fix. If this can work right in the one-by-one service mode. it is unacceptable. It maybe run fine in parallel but just from luck.
I am having the same problem of net.lo starting right before local as well except famd is failing because of it. Tried the suggestion of RC_PARALLEL_STARTUP="yes" and problem is cured for now, but as mentioned this is just a work around and not a fix as the default behaviour seems to be broken. Also this is on a x86 system so it seems to go beyond a AMD64 problem. Shea
*** Bug 106119 has been marked as a duplicate of this bug. ***
I've tried everything here and in forums the only workaround on my box is setting RC_STRICT_NET_CHECKING to "yes" and with this set to yes, my "lo" comes up in console in run lvl 3 right before mysql RD
o - and eth0 is still booting in background eth0 don't even show up in console RD
I'm having the same problem. nfs & nfsmount starts before net.lo & net.eth0 and fail. I even tried to bypass it by moving net.* to boot level and it helps only 50% of the time, part of the boots net services still starts only at the end. It looks like a dependency problem. I'm using baselayout 1.12.0_pre8-r2, without parallete startup feature.
Actually, this also affects samba if it is configured to work with cups, as samba cannot reach the cups server. net.lo is started AFTER init.d/local. Another weired thing is that also the dhcpcd started very late (after local and and even net.lo!), but a IP address is assigned with DHCP very early ?!
All righty then - I think I've found the problem. Either a baselayout ebuild or a stage3 tarball has placed invalid default links in /etc/runlevels. baselayout-1.12.0_pre10 ships with an improved rc-status that will display the word "broken" for broken runlevel links regardless of if it's started/stopped/whatever. If you see a broken link here's how you fix it : rc-update del $service rc-update add $service $runlevel (where $service is the broken service and $runlevel is the runlevel it was broken in) If that fails to fix it, please download this script http://dev.gentoo.org/~uberlord/baselayout/trace-test Into /etc/init.d, start it and then attach the results here. Re-open this bug too ....
