Although /lib/rcscripts/net/pppd.sh waits in case of 'updetach' with ifconfig/iproute2 for the interface, it may happen that this interface is ready before pppd has finished everything (e.g. I observed that it will usually return before all scripts in /etc/ppp/ip-up.d are executed). Moreover, probably for the same reason, I usually even get a warning saying that ppp0 is up but not active (to the effect that the return code of "/etc/init.d/net.ppp0 start" is not 0 although the interface will be working some seconds later). I guess if you want to reproduce the problem you should perhaps put some sleep's into the /etc/ppp/ip-up.d scripts. However, I am not sure about the reason: Either the problem is that start-stop-daemon sends pppd immediately in the background and does not wait until it would finish normally even in case of ${hasupdetach}? Or maybe this bug is actualy not related with baselayout but with net-dialup/ppp (tested with 2.4.4-r13)?
If I understand you correctly, what you are describing is NOT a bug. Basically, pppd.sh knows that pppd will continue the interface configuration when it has a connection so it stops and goes inactive. inactive means that the interface is "down", but has a controlling daemon to fully bring it "up". ifplugd does the same for cable in/out for wired and wpa_supplicant for wireless networks. If you disagree then maybe mrness could shed more light on this.
This is not related to baselayout in any way. And yes, it is not a bug, it is the way pppd was designed. When updetach option is specified, pppd will detach as soon as PPP negociation ends. You will have an IP on ppp interface and everything, but the ip-up script might still run.
Thanks for the explanation. In this case, baselayout would either need some option so that /etc/init.d/net.ppp0 waits (with a timeout) until the interface is active, or "need net.ppp0" would have to wait until this happens: Otherwise, it might happen that some service are sometimes started and sometimes not started (depending on whether the interface could be activated "fast enough").
The current default is that a virtual service is defined by services that provide it in the boot and current runlevels. So net.lo provides "net" by default. If you wish net.ppp0 to be included in this, then either add it to your default runlevel OR add RC_NEED="net.ppp0" to the /etc/conf.d/foo where foo is the name of the service that needs this dependency.
If I remember correctly, services that satisfy the following conditions: 1) are listed in the current runlevel 2) depend on net.ppp0 will get started on inactive->started transition of the net.ppp0 service and will get stopped on started->inactive transition. Or am I wrong?
You are right. I was confused about some manually started services (not in the current runlevel) which did explicitly depend on net.ppp0: Since they returned a nonzero value and did not produce their usual output, I false believed that they were not started. I did not realize that they were started later automatically once net.ppp0 got active. Sorry for the noise.
