Since my upgrade to networkmanager-0.9.2.0-r4, I noticed that networkmanager hangs my box for 5 seconds during the boot process and also it load a lot of modem modules on my box automagically that aren't use on my box. Reproducible: Always Steps to Reproduce: 1. time emerge -auDNv @world 2. 3. Actual Results: rc boot logging started at Mon Feb 20 16:49:45 2012 * Setting system clock using the hardware clock [Local Time] ... [ ok ] * Loading module vboxdrv ... [ ok ] * Loading module vboxnetflt ... [ ok ] * Loading module vboxnetadp ... [ ok ] * Autoloaded 3 module(s) * Checking local filesystems ... /dev/sda8: clean, 371468/6455296 files, 2091570/25802222 blocks /dev/sda7: clean, 214/26104 files, 15280/104388 blocks [ ok ] * Remounting root filesystem read/write ... [ ok ] * Updating /etc/mtab ... [ ok ] * Mounting local filesystems ... [ ok ] * Configuring kernel parameters ... [ ok ] * Creating user login records ... [ ok ] * Cleaning /var/run ... [ ok ] * Wiping /tmp directory ... [ ok ] * Restoring Mixer Levels ... [ ok ] * Setting hostname to funtootux ... [ ok ] * Setting terminal encoding [UTF-8] ... [ ok ] * Setting keyboard mode [UTF-8] ... [ ok ] * Loading key mappings [cf] ... [ ok ] * Mounting USB device filesystem [usbfs] ... [ ok ] * Activating swap devices ... [ ok ] * udev: storing persistent rules ... [ ok ] [ ok ] * Initializing random number generator ... [ ok ] rc boot logging stopped at Mon Feb 20 21:49:49 2012 rc default logging started at Mon Feb 20 21:49:49 2012 * Starting D-BUS system messagebus ... [ ok ] * Starting NetworkManager ... [ ok ] Connecting 5sConnecting... 4sConnecting...... 3sConnecting......... 2sConnecting............ 1sConnecting............... * WARNING: NetworkManager has started, but is inactive * Starting metalog ... [ ok ] * Starting ConsoleKit daemon ... [ ok ] * WARNING: netmount is scheduled to start when NetworkManager has started * Setting up gdm ... [ ok ] * Starting cupsd ... [ ok ] * Starting vixie-cron ... [ ok ] * Starting local [ ok ] Expected Results: I would like to see the timeout remove or at least have a use flag to remove the need to load a lot of modem modules. During the boot time, I saw a lot of these just before the 5 sec timeout : modem-manager[2005]: <info> Loaded Plugin Option High-Speed modem-manager[2005]: <info> Loaded Plugin Samsung modem-manager[2005]: <info> Loaded Plugin Wavecom etc...
Thanks for the suggestion; I have made the timeout configurable via INACTIVE_TIMEOUT variable in /etc/conf.d/NetworkManager, and reduced it to 1 second by default. PS. If you don't want to load modems, simply emerge networkmanager with USE=-ppp, and unmerge modemmanager. +*networkmanager-0.9.2.0-r5 (21 Feb 2012) + + 21 Feb 2012; Alexandre Rostovtsev <tetromino@gentoo.org> + -networkmanager-0.9.2.0-r4.ebuild, +networkmanager-0.9.2.0-r5.ebuild, + files/networkmanager-0.9.2.0-init-provide-net-r1.patch, + +files/conf.d.NetworkManager: + Make timeout to go inactive at init.d script startup configurable, and reduce + it to 1 second by default (bug #405141, thanks to Sylvain Alain).
and what about simply not waiting at all and relying on it being set "active" when really connected? (the problem is that I don't know how much time passes between checks for "activity" :S)
I'm not sure but removing the ppp use flag will remove the vpn feature too. Thanks for the fix.
(In reply to comment #2) When the timeout runs out, /etc/init.d/NetworkManager is marked inactive and goes into background mode; it (and all the services that depend on net!) will still start as soon as a connection is established (a dispatcher script takes care of this), but nothing will be printed to the terminal when it happens. Therefore, there is a tradeoff. On the one hand, a timeout that's sufficiently long to establish a connection means you get to see which services want to start, and which of them start and which fail. On the other hand, a short timeout means that at boot, your machine gets to the login screen faster. And for setups where a connection requires the user to input a password, or if the connection was saved as per-user and not systemwide, any timeout is a useless waste. I chose 1 second as a compromise. It is probably sufficient for an ethernet connection to be established, and so lets admins of machines with systemwide ethernet connections see the list of services started while booting, while not delaying boot too much for users with wireless or modem connections. If you primarily use wireless connections and do not want to wait for any timeout at boot, you can set INACTIVE_TIMEOUT=0 in /etc/conf.d/NetworkManager.
I am not happy with any of the recent changes, and all releases post 0.9.2.0-r2 are broken, possibly all after 0.9.2.0. Using wired ethernet and INACTIVE_TIMEOUT=10, I still get a message that NM is inactive and that network services are not being started. Something is clearly wrong here. I think this whole "inactive" state is a mistake, and I would like to have the 0.9.2.0 behaviour back where NM and all network services just start start. Starting services explicitly configured for a certain runlevel in the background and not informing users on the console is really bad design. I'm happy to have NM block until net is *really* provided, time to login screen is a secondary consideration when the trade-off is a broken rc system.
Created attachment 303015 [details] Demonstrate slow startup The attached file shows how it can take in the order of 10s for an ethernet interface to be fully ready. I don't know what causes the delay.
(In reply to comment #5) Old networkmanager without the inactive state was causing all sorts of crashes and failures (for example, see comments in bug #252137 or #345365). We are not going back to it. Starting an openrc service in the background if it does not start in the foreground after a short timeout is the least bad design for services whose startup time can be unpredictably long. It was not something that was invented for networkmanager; for example, /etc/init.d/net.ppp0 behaves the same. If your router is slow at serving dhcp requests and you are not using a static IP, 10 seconds might not be enough; if you really, really want /etc/init.d/NetworkManager to start in the foreground and don't care about the effect boot time, consider increasing INACTIVE_TIMEOUT to 30 or even 60 seconds.
As I see it, the lease is granted in less than a second, and the delay is caused by NM. It takes NM five seconds to register the fact that a lease was granted.
