[SOLVED] I can't manage NetworkManager via /etc/rc.d/rc.networkmanager script

I can't repeat that behaviour here (14.2 x86_64, no multilib). Immediately after a reboot, I see:

chris@d6:~$ nmcli -p g
=========================
  NetworkManager status
=========================
STATE      CONNECTIVITY  WIFI-HW  WIFI     WWAN-HW  WWAN    
--------------------------------------------------------------------------------------
connected  full          enabled  enabled  enabled  enabled 
chris@d6:~$ sudo /etc/rc.d/rc.networkmanager restart
Password: 
Stopping NetworkManager: stopped
Starting NetworkManager daemon:  /usr/sbin/NetworkManager
chris@d6:~$ nmcli -p g
=========================
  NetworkManager status
=========================
STATE       CONNECTIVITY  WIFI-HW  WIFI     WWAN-HW  WWAN    
---------------------------------------------------------------------------------------
connecting  unknown       enabled  enabled  enabled  enabled 
chris@d6:~$ nmcli -p g
=========================
  NetworkManager status
=========================
STATE      CONNECTIVITY  WIFI-HW  WIFI     WWAN-HW  WWAN    
--------------------------------------------------------------------------------------
connected  full          enabled  enabled  enabled  enabled 
chris@d6:~$

Notice that the first nmcli after networkmanager restart didn't fully succeed because STATE was then still connecting. Running the same command a few seconds later resulted in full success. There was no restart of messagebus needed.

chris

Thank you chris.willing. But still no avail. Slept 30 sec before trying to connect to NetworkManager - again the same error. But at least I think I located the problem which I think now lies in startup of D-Bus. I made both /etc/rc.d/rc.messagebus and /etc/rc.d/rc.networkmanager non-executable, rebooted the system and then started them both manually and with this procedure I obtained the same behavior - error after NetworkManager restart. Restarting /etc/rc.d/rc.messagebus fixes the problem.

Edit: I solved the problem! The true source of my problems with NetworkManger is combination of dbus-launch command and su command. Ok, in conclusion instead of

$ su
# /etc/rc.d/rc.networkmanager restart

I should use

$ su -l
# /etc/rc.d/rc.networkmanager restart

Thanks to everyone posted in this thread.

I should use

Good job!

Originally Posted by upnort Good job!

Thanks! I can only say that even if the solution I found looks little stupid explanation why actually use "su -l" instead of just "su" is rather complicated. So I didn't even try. However I can post the main clue I found in manual for dbus-launch

The second common reason for autolaunch is an su to another user, and display of X applications running as the second user on the display belonging to the first user. Perhaps the ideal fix in this case would be to allow the second user to connect to the session bus of the first user, just as they can connect to the first user's display. However, a mechanism for that has not been coded.

the second from /var/log/messages

NetworkManager[2623]: <info> [1521653803.6970] bus-manager: could not connect to the system bus (Timeout was reached); only the private D-Bus socket will be available

I mean the word "private" started to worry me.

Look at my first post in this thread, where I mentioned the log spew implied a permissions problem. When using su rather than su - the elevation to root privileges is different. One of the differences is su inherits the non-root user's environment variables rather than create new variables. This difference affects d-bus ($DBUS_SESSION_BUS_ADDRESS).

BTW, you can use su - rather than su -l to save a keystroke.

Originally Posted by upnort Look at my first post in this thread

exactly this gave me clue to look for D-Bus. But in fact the main step I did when I started system in run level 3 - and noticed than in this level everything is ok. Now in all wm's I noticed the same strange behavior - except one - twm. But this is the only window manager which starts without D-Bus. I mean if someone is using xwmconfig command - then all scripts - except one - call directly or indirectly dbus-launch .

BTW, you can use su - rather than su -l to save a keystroke.

I think that in thread su -l looks better. Self-explanatory.

The other thought which came to me is how far this goes - I mean strange behavior of some applications caused by execution in "private" D-Bus environement (?). I mean application D-bus aware. Such strange behavior can be problematic to diagnose as my own problem was. In fact my first solution was instead of to use su -l - simply to unset variable DBUS_SESSION_BUS_ADDRESS after su . Doing su -l makes me to feel little uncomfortable. But well, if there is no particular danger su -l is straightforward.