# NetworkManager has started, but is inactive

## Princess Nell

After emerging the latest networkmanager update, I get warnings during boot:

```

* Starting NetworkManager ...                                                                                                                       [ok] 

* WARNING: NetworkManager has started, but is inactive

* WARNING: netmount is scheduled to start when NetworkManager has started

* WARNING: gkrellmd is scheduled to start when NetworkManager has started

* WARNING: sshd is scheduled to start when NetworkManager has started

```

The reason appears to be (networkmanager-0.9.2.0-r3.ebuild changelog):

```

Change the NetworkManager OpenRC service to provide net; the service's status

  is set to 'inactive' when NetworkManager is running but has no connections

  up, and to 'started' when NetworkManager is connected

...

```

These services appear to be available when I'm logged in.

I'm not saying this change is bad, but it's designed badly. The boot screen does not report the system in proper working order, although these services appear to be running when I login. NM should wait until an interface is active and then the other services requiring net start up correctly *and* report their status correctly.

I don't really care about the latest "shave 0.2 microseconds off startup time" fad, I want a system that works correctly and reports itself accordingly.

I thought I could get rid of the warnings by switching from wireless to wired, but it makes no difference.

----------

## Leio

Do you have your NetworkManager home connections marked as "Available to all users"? I think then it should be connecting early in the console as well, before logging in a user.

Not sure that's your issue here though, just an idea.

----------

## Princess Nell

Yes, they are available to all users.

The issue is not with connecting early enough. Everything that is supposed to happen, does happen, but it is reported wrong or not at all.

I want services requiring net and starting at boot to launch exactly when they're supposed to *and* report to that effect. Printing a warning and having them launched asynchronously and anonymously in the background is not helpful. I should not be required having to verify that the services are actually running. The computer is working for me, not the other way round.

----------

## Princess Nell

The more I look at it, the more frustrating it becomes.

Let's say I bring my machine into work and connect to the hidden, wireless network.

On my 32-bit system, with networkmanager 0.9.2.0 and defaulting to wireless, NM and network services show up as started and OK on the boot screen. Yet, I can clearly tell the network interface isn't active until around the time gdm is loading. This is not correct, obviously.

When I downgrade the 64-bit system to the same version of NM (apples and oranges, yadda yadda), all network services show up as started and OK on the boot screen, but there is no network connection. When I login, all my configured wireless networks have disappeared (i.e. the configurations have disappeared from NM). I recreate the wireless network config, but NM doesn't connect automatically, I have to explicitly "connect to hidden wireless network". When I reboot and login, the wireless connection has disappeared again.

Now remove the mask on 64-bit and move to NM 0.9.2.0-r4. Reboot, then recreate the wireless config. Reboot again.

Try the wired network this time. NM is "Connecting ..." and counting down. At about two seconds, I get both activity lights on the NIC. Machine boots up fully while telling me that the various network services are "scheduled to start when NM has started". Now I login, open NM, edit connections, and find that the configuration for my home network has magically reappeared - it is the only wireless connection configured. Then I add the work wireless network and once this is complete, there are two copies of it. I disconnect the ethernet and turn on wireless. Again, there is no automatic connection and I need to connect explicitly.

Now reboot. nm-dispatcher.action script informs the that the openrc status script from dispatcher.d exits with status 1. ??

Upon reboot I see the new behaviour I've been complaining about (network services not started because NM inactive), but the wireless connection activates around the time gdm comes up. Open edit connections in NM and I see only one copy of the current wireless config. So, at least it seems to be working, but on shutdown, the nm-dispatcher.action script again fails with exit status 1.

I've tried to do a thorough debug but I guess that some of the inconsistent behaviour I described above may well be caused by switching versions up and down. How can one *completely* remove any existing configuration?

The main problem remains: even with a wired connection, NM is inactive and network services remain unstarted until gdm comes up. -r4 makes the situation worse with a failing dispatcher script on shutdown.

I find the 0.9.2.0 behaviour (start network services and report them started) slightly more preferable. But again, ideally, NM should block until a connection is up. Non-NM based systems are managing to do this just fine.

----------

## RazielFMX

I am also having this issue.  I thought maybe it was a timeout on dhcpcd (when networkmanager .9.2-r4 starts, there is a 5 second countdown that is displayed on the console before this error message is displayed), since dhcpcd used to take 10-15 seconds to get an IP address back when I was using net.eth0 instead of NetworkManager to start my wired interface.

This is my current configuration:

```
$ cat /etc/NetworkManager/nm-system-settings.conf

[main]

plugins=keyfile

[ifupdown]

managed=true

auto_refresh=false

```

What is odd is that this file probably should be named NetworkManager.conf, but every time I install a new version it seems to ignore it and install this file (probably an issue with the ebuild) even though it is deprecated.  So for now, I use the deprecated file name.

I've done some testing (basically removed xdm from startup so I boot right to console prompt for speed) and by the time I have a console prompt I have full network access, so I really believe it is NetworkManager not waiting for dhcpcd to complete the dhcp transaction.

----------

## Princess Nell

That 5s delay ... somehow, a hard-coded delay doesn't strike me as appropriate in an event-driven environment. -r4 certainly makes matters worse than even -r3.

----------

## mva

Hi, guys!

Isn't it any solution for this problem yet?

----------

## slackline

Looking for soultions to this too.

I've the same config file as RazielFMX (although its called /etc/NetworkManager/NetworkManager.conf).

After booting up I can't ssh in, but if I manually start sshd then I can connect no problem.

Considering trying wicd as an alternative network manager as it doesn't differ that much from Network Manager, but suspect it may suffer from a similar problem as it appears to be a problem with the init scripts.

slack

----------

## khayyam

 *slack---line wrote:*   

> Considering trying wicd as an alternative network manager as it doesn't differ that much from Network Manager, but suspect it may suffer from a similar problem as it appears to be a problem with the init scripts.

 

slack---line ... no, I do not think it is an issue with the init scripts, or openrc, it is the mixture of 'dependent' and 'independent' methods of handling status.

For openrc a service is dependent on other services being available, so, if a service like ntpd needs net, then net must be provided for the dependency to be met. NetworkManager on the hand is an independent agent, its not neccessary for anything to be provided for it to start, as it'll 'manage' these requirements subsequently. The question is, what is the agents role in a dependency chain when it is its own arbiter in the process? Indeed, should the method provided by init be handed over to the agent, after all, that is how it is designed to operate.

In order to accomodate this design, openrc is simply passing on the dependency to NetworkManager, saying "ok, you now provide net", but NetworkManager doesn't give a rats poop about provison, its set to 'manage'; meaning that , if it starts with 'net' or not, no biggie, 'net' is one click and configure away. Way back in init land, other dependent services are either failing or waiting for 'net', but NetworkManager is happily managing the whole thing by virtue of its independent status.

So, who to blame, "... the fault, dear Brutus, lies not in the stars, but in ourselves", and the best I think openrc, or gentoo, can do is offer its apologies for ruining redhats (top down) design.

If, as Princess Nell has asked, openrc should wait on NetworkManager to succeed in providing net prior to starting dependent services, then I can only ask ... how? Its not NetworkMangers job to provide anything, its an independent manager in this organisation. So, either the init process is handed over to NetworkManager, or NetworkManager is redesigned to run as a co-dependent in the init process, but I don't think both can coeixst as they are currently. Likely, at this point, you should be running a fully redhat supported init system ... or stop looking to the lay of the stars for reasons. I don't mean that to be taken harshly, but I think that is the reality.

best ... khay

----------

## slackline

Thanks for the explanation, had sort of realised that NetworkManager is somewhat autonomous but thought openrc would have still had sshd waiting for a valid connection to be made at some point by something.

I wonder if/why the 'provide net' solution for wicd explained here doesn't work with Network Manager (as 'provide net' is in /etc/init.d/NetworkManager).

I'll pass on switching to redhat, only ever installed 7.3 when I first tried Linux distros and the circular dependencies were a nightmare.  Quickly switched to Slackware but that was superseded by Gentoo which I've been quite happy with for about seven years now (although obviously I've still a lot to learn, one of the reasons I continue stick with it   :Wink:  ).  You lost me on the analogy of looking to the lay of the stars though, is that a reference to the nonce sense of astrology?

----------

## khayyam

 *slack---line wrote:*   

> Thanks for the explanation, had sort of realised that NetworkManager is somewhat autonomous but thought openrc would have still had sshd waiting for a valid connection to be made at some point by something.

 

slack---line ... you're welcome. The problem is that once openrc hands off to NetworkManager and has it provide net, then all openrc, and any subsequent services that require net, can do is wait for net to be provided, but again, NetworkManager isn't providing net but a management service, which is an entirely different model to init.   

 *slack---line wrote:*   

> I wonder if/why the 'provide net' solution for wicd explained here doesn't work with Network Manager (as 'provide net' is in /etc/init.d/NetworkManager).

 

In the case of init its task is to bring the system up in a way that is consistant, robust, and dependable, to do this each component (which can either be a service, script, or what-have-you ... given the modular "one tool that does one thing and does it well" design) is seen in relation to other components, hardisks are mounted, modules loaded, etc, etc, each in relation to subsequent requirements (its essencially a synchronous model). I say "consistant, robust, and dependable" because that is its key purpose, other considerations (such as speed, interaction, etc) are secondary (though it should be noted that though synchronous it is flexable as huristics can be applied dependent on succcess/failure, etc). Once this process is completed init practically disapears from the scene leaving services, etc, to work things out amongst themeselves (the exception being the inittab run by init to respawn should some process need it). The entire process subsequent to init is dependent on cooperation between services, their ties, dependencies, interrelations, etc, init is nolonger running the show, but expects that whomever is passed the task of, say 'providing net', will take all other services into account, in a manner that is consistant with init's mandate. So, NetworkManager is passed the task of providing 'net', but its designed as something altogether unrelated to the underlying init system, it has its own managerial agenda and its own independent conception of subsequent dependency, cooperation, etc. The essence of init, is to be simple, extensible, and flexible, all for the sake of consistancy, robustness and dependability. NetworkManager is an like an alien apendature to this model, and has its roots in a top-down interface driven model of the OS. So, why doesn't it "work"? Well, I would say that its broken by design, but obviously this is a claim that I would need to substanciate by showing how init (regardless of its limitations) is superior in this regard, but I think this is perhaps a difficult task because init and NetworkManager are designed with entriely different conceptions of the OS (bottom up, as opposed to top down), and this is where *nix (histrorically) stood in distinction to the OS driven by the user interface, and that, imo, is the crux of the problem.  

 *slack---line wrote:*   

> I'll pass on switching to redhat, only ever installed 7.3 when I first tried Linux distros and the circular dependencies were a nightmare.  Quickly switched to Slackware but that was superseded by Gentoo which I've been quite happy with for about seven years now (although obviously I've still a lot to learn, one of the reasons I continue stick with it).

 

The "using a redhat supported init system" was ment to drive home the point, its not a question of the OS, distribution, etc, but the forces driving development.

 *slack---line wrote:*   

> You lost me on the analogy of looking to the lay of the stars though, is that a reference to the nonce sense of astrology?

 

No, its a reference to complicity, "the fault lies in ourselves" not the stars. If users accept the OS model that is being promoted by redhat, gnome, freedesktop, etc, that is, if developement is driven by the good idea fairy and not users, then the fault is as much with the users as those drivng development.

best ... khay

----------

## slackline

Cheers for the further insights.

Do you have any suggestions other than the traditional linking of /etc/init.d/net.wlan0 -> /etc/init.d/net.lo and adding it to default as to how to manage wireless connections or is this the correct way of brining up the interfaces under the bottom up model.  If so do you (or anyone else) know if this conflicts with then using wicd/NetworkManager to manage wireless connections?

This is really the first time I've played with Gentoo on a laptop in about six years so I've little practice/experience of wireless under Gentoo (or Linux systems more generally).

Cheers,

slack

----------

## khayyam

 *slack---line wrote:*   

> Do you have any suggestions other than the traditional linking of /etc/init.d/net.wlan0 -> /etc/init.d/net.lo and adding it to default as to how to manage wireless connections or is this the correct way of brining up the interfaces under the bottom up model. If so do you (or anyone else) know if this conflicts with then using wicd/NetworkManager to manage wireless connections?

 

slack---line ... the "conflict" is in the "bringing up", its a definite proposition, not a maybe. If there are maybe's involved then whatever is managing subsequent actions needs to be intergrated in such a way that once asigned the task of providing 'net' it also provides for other services. This intergration is lacking because these managers are designed with either a specific init in mind, and/or to be independent of it.

As for possible methods of accomodating wicd/NetworkManager the best that openrc can do is say "ok, you are providing net", and to hand off responcibility, but as we've seen anything else set in that run-level that 'needs net' can only be "[...] scheduled to start when [foo] has started".

My way of handling net is to have nothing in the default run-level that 'needs net' and have run-levels ("softlevels") for various network setups (ie: "online"). With these set I can call softlevel=online from the bootloader or 'rc online' once booted. It is then up to whatever is in /etc/conf.d/net to configure the interface as required. On the odd occasion I might use 'wpa_cli select_network [N]' or wpa_cli's interactive shell, if something other than my regular setup is required, but mostly I never need to worry about it as openrc is more than capable of handling the situation. With the above it never takes any more than a few seconds to have everything set, and I can switch between network setups (including ad hoc, firewall rulesets, network services, etc) consistantly and dependably. For me openrc works perfectly, and I have absolutely no need of wicd/NetworkManager ...

best ... khay

----------

