My /etc/conf.d/net contains a configuration for eth0. The eth0 interface is started with this configuration whenever net.lo is executed during the boot runlevel (quite early). This happens in spite of an explicit net.eth0 link in "default" (and no such link in "boot"), and even if neither the boot runlevel nor the default runlevel contain an net.eth0 link. This is a very bad idea in my environment: net.lo should only start the lo interface, eth0 should be initialized during the default runlevel startup, as it depends on other things started in "default". How do I configure net.lo to bring up lo only as its name suggests (and a separate net.eth0 to bring up eth0 later)? Reproducible: Always Steps to Reproduce: Boot with eth0 configured in /etc/conf.d/net, but no net.eth0 in /etc/runlevels/* Actual Results: Watch the startup messages: eth0 comes up immediately after lo Expected Results: eth0 should not be initialized at all, or at a later time if there is a net.eth0 in the default runlevel.
I would guess this is because eth0 was coldplugged by udev. So either stop that from happening in udev or in openrc by editing /etc/rc.conf accordingly. Coldplugged services need to happen in the boot runlevel, and you've yet to state why it's bad and why it requires things in default. You can also merge boot and default by removing the boot runlevel from /etc/inittab.
My situation is the following: * eth0 is linked into the kernel, and the physical link is up from the very beginning. * There is udev with coldplug, but no hotplug. * eth0 is configured by dhcp, and the dhcp client is configured to retry infinitely (hence, net.eth0 hangs and blocks the boot process until the computer receives a dhcp address). * The dhcp server is usually powered up at the same time, and establishes a remote connection before providing any dhcp addresses for lease. * This may take quite a variable amount of time: Sometimes, the dhcp server is already providing leases when eth0 is configured, sometimes, the dhcp client has to wait 5 minutes or more. Now what I want: * I want to be able to work locally while the dhcp client is still waiting. * I want all services which depend on eth0 to be started immediately and automatically after eth0 gets its lease, no matter if that takes 10 seconds or 10 minutes. * Most important: I need some ability to log in and stop / kill the dhcp client (and finish the boot without the network services) if dhcp is really broken (for example, if the dhcp server cannot establich its remote connection). The last thing is the one which causes headache: Currently, with eth0 started at the boot level, *before* any getty terminal and before X, I have no chance to log in or to just bring the machine down again if the dhcp server doesn't serve - the boot level hangs forever. How do I do that right?
This behavior conflicts with sys-apps/netplug. Before openrc, eth0-dependent services were started in the background, now i.e. ntpd is started in the foreground.
As recommended in #1, I suppressed coldplug for net.eth0, and now things seem to work the way I need them.
Is there still an outstanding issue here? This bug seems to be a multitude of questions.
All the problems were caused by lack of documentation: I expected eth0 to be started at the runlevel to which net.eth0 is linked, based on the dependencies explicitely given in net.eth0 (which is what one would expect from any init.d file). However, this is not the case: eth0 is started much earlier, based on udev and coldplug, which is turned on by the default installation (and if starting eth0 hangs forever, the whole bootstraping hangs in an early stage, and there is no way to log on). If coldplug is disabled for eth0, everything works as expected (at least for me). Hence, there is no technical problem. But: * Either this coldplug behaviour overriding the net.eth0 file and the runlevel start order must be clearly documented. * Or coldplug should not be enabled by default?
Does this actually deviate from baselayout-1 behavior? I believe baselayout-1 will behave the same way with a recent enough version of udev.
No idea how baselayout-1 behaves / behaved (this was on a newly installed machine). But as I said before: I don't know if the behaviour or the documentation needs fixing. The "problem" is that if you link net.eth0 to some runlevel and state some dependencies in it, you naturally expect that the system will start eth0 only based on that. There is no obvious hint that eth0 will be started much earlier due to coldplug, without obeying the dependencies and runlevel. Perhaps it is just that hint which is missing: The guide about startup, runlevels and init.d files should also prominently mention the coldplug mechanism!
This problem repeatedly crops up - maybe we should disable service hotplug by default?
(In reply to comment #9) > This problem repeatedly crops up - maybe we should disable service hotplug by > default? > I think there is reasonable defaults as-is. With now over a year since the last activity on this bug, I think it is safe to close. Anyone else have an opinion?
(In reply to comment #10) > (In reply to comment #9) > > This problem repeatedly crops up - maybe we should disable service hotplug by > > default? > > > I think there is reasonable defaults as-is. With now over a year since the last > activity on this bug, I think it is safe to close. Anyone else have an opinion? Agreed, I'm closing this. Please re-open if this is still an issue. Thanks, William
