After upgrading networkmanager to 1.4.0-r1 it stopped to connect to networks that are marked as "Automatically connect to this network when it's available". Manually connecting to the network still works. A Workaround is to set the option "All users may connect to this network" which leads to working autoconnects again but autoconnect should work without this option enabled. [ebuild R ] net-misc/networkmanager-1.4.0-r1::gentoo USE="consolekit gnutls introspection json modemmanager ncurses ppp wext wifi -audit -bluetooth -connection-sharing -dhclient -nss -ofono -resolvconf (-selinux) -systemd -teamd {-test} -vala" ABI_X86="(64) -32 (-x32)" 0 KiB
downgrading networkmanager to net-misc/networkmanager-1.0.12-r1 also works
I can confirm this behaviour. I am using up-to-date Gentoo amd64 and experience the same problem as reported by the Herbert Wantesh since I upgraded to networkmanager-1.4.0-r1. His suggested work-around works in my case too, but it is not a solution. networkmanager-1.0.12-r1 works in my case too. $ eix -I net-misc/networkmanager [I] net-misc/networkmanager Available versions: 1.0.12-r1 ~1.2.4 ~1.4.0 1.4.0-r1 ~1.4.2 {audit bluetooth connection-sharing consolekit +dhclient dhcpcd gnutls +introspection json +modemmanager ncurses +nss ofono +ppp resolvconf selinux systemd teamd test vala +wext +wifi zeroconf ABI_MIPS="n32 n64 o32" ABI_PPC="32 64" ABI_S390="32 64" ABI_X86="32 64 x32" KERNEL="linux"} Installed versions: 1.4.0-r1(16:36:22 01/10/16)(bluetooth consolekit dhclient introspection modemmanager ncurses nss ppp wext wifi -audit -connection-sharing -gnutls -json -ofono -resolvconf -selinux -systemd -teamd -test -vala ABI_MIPS="-n32 -n64 -o32" ABI_PPC="-32 -64" ABI_S390="-32 -64" ABI_X86="64 -32 -x32" KERNEL="linux") Homepage: https://wiki.gnome.org/Projects/NetworkManager Description: A set of co-operative tools that make networking simple and straightforward
How does networkmanager-1.4.2 work for you?
(In reply to Pacho Ramos from comment #3) > How does networkmanager-1.4.2 work for you? same behavior as 1.4.0-r1
btw. i could reproduce this behavior on multiple gentoo installations
I would report this directly to upstream then -> bugzilla.gnome.org
Same behavior here with up-to-date Plasma on amd64
I can also confirm this behaviour on amd64 with up-to-date Plasma.
I filed a bug report at https://bugzilla.gnome.org/show_bug.cgi?id=772640. And the solution is to use this patch - https://bugzilla.gnome.org/attachment.cgi?id=337514&action=diff.
seems something is missing, as i have to restart networkmanager after every reboot to get it working
it seems consolekit wasn't up for whatever reason, after starting it, nm works even after a reboot. so the patch is correct
Unfortunately the patch does not appear to work in my case; 'All users may connect to this network' must still be ticked in the Gentoo amd64 installation on my Clevo W230SS laptop. This is what I have currently: # rc-update show -v | grep consolekit consolekit | default # rc-status | grep consolekit consolekit [ started ] # ls /etc/portage/patches/net-misc/networkmanager-1.4.0-r1 0002-session-monitor-fix-parsing-of-ConsoleKit-database.patch # eix -I networkmanager [I] kde-frameworks/networkmanager-qt Available versions: (5) 5.23.0(5/5.23) 5.26.0(5/5.26) 5.26.0-r1(5/5.26) {debug teamd test} Installed versions: 5.26.0-r1(5)(18:17:30 08/10/16)(-debug -teamd -test) Homepage: https://www.kde.org/ Description: NetworkManager bindings for Qt [I] net-misc/networkmanager Available versions: 1.0.12-r1 ~1.2.4 ~1.4.0 1.4.0-r1 ~1.4.2 {audit bluetooth connection-sharing consolekit +dhclient dhcpcd gnutls +introspection json +modemmanager ncurses +nss ofono +ppp resolvconf selinux systemd teamd test vala +wext +wifi zeroconf ABI_MIPS="n32 n64 o32" ABI_PPC="32 64" ABI_S390="32 64" ABI_X86="32 64 x32" KERNEL="linux"} Installed versions: 1.4.0-r1(17:12:03 13/10/16)(bluetooth consolekit dhclient introspection modemmanager ncurses nss ppp wext wifi -audit -connection-sharing -gnutls -json -ofono -resolvconf -selinux -systemd -teamd -test -vala ABI_MIPS="-n32 -n64 -o32" ABI_PPC="-32 -64" ABI_S390="-32 -64" ABI_X86="64 -32 -x32" KERNEL="linux") Homepage: https://wiki.gnome.org/Projects/NetworkManager Description: A set of co-operative tools that make networking simple and straightforward Found 2 matches # cat /etc/NetworkManager/system-connections/eth0 [connection] id=eth0 uuid=<annonimised by me> type=ethernet permissions=user:fitzcarraldo:; secondaries= [ethernet] mac-address=<annonimised by me> mac-address-blacklist= [ipv4] dns-search= may-fail=false method=auto [ipv6] addr-gen-mode=stable-privacy dns-search= method=ignore
try to restart networkmanager while already logged. does it automatically connect afterwards?
and please post the complete output of rc-status.
In response to Comment 13 and Comment 14 1. Immediately after rebooting and logging in to Plasma 5: clevow230ss fitzcarraldo # rc-status Runlevel: default dbus [ started ] NetworkManager [ inactive ] netmount [ scheduled ] syslog-ng [ started ] cupsd [ started ] samba [ scheduled ] consolekit [ started ] cronie [ started ] clamd [ started ] bluetooth [ started ] xdm [ started ] cups-browsed [ started ] sshd [ started ] local [ started ] Dynamic Runlevel: hotplugged Dynamic Runlevel: needed/wanted modules-load [ started ] xdm-setup [ started ] avahi-daemon [ started ] Dynamic Runlevel: manual clevow230ss fitzcarraldo # 2. Now restart NetworkManager from Konsole: clevow230ss fitzcarraldo # /etc/init.d/NetworkManager restart * Stopping NetworkManager ... [ ok ] * Starting NetworkManager ... [ ok ] Connecting....... 0sclevow230ss fitzcarraldo # Restarting NetworkManager whilst logged in to KDE results in the connection named 'eth0' becoming active, and the plasma-nm icon on the Panel now indicates that the connection has become active. 3. After Step 2 has been performed: clevow230ss fitzcarraldo # rc-status Runlevel: default dbus [ started ] NetworkManager [ started ] netmount [ stopped ] syslog-ng [ started ] cupsd [ started ] samba [ stopped ] consolekit [ started ] cronie [ started ] clamd [ started ] bluetooth [ started ] xdm [ started ] cups-browsed [ started ] sshd [ started ] local [ started ] Dynamic Runlevel: hotplugged Dynamic Runlevel: needed/wanted modules-load [ started ] xdm-setup [ started ] avahi-daemon [ started ] Dynamic Runlevel: manual ntp-client [ started ] clevow230ss fitzcarraldo #
at seems that networkmanager is started before consolekit and therefore NetworkManager knows nothing about consolekit, the restarte of it let it see consolekit and therefore it works afterwards. Did you add Networkmanager to any runlevel? if yes try to remove it from that runlevel and reboot.
maybe someone should add consolekit as "need" to the Networkmanager init script when the consolekit useflag is set, to avoid Networkmanager getting started before consolekit like: /etc/init.d/NetworkManager: depend() { need dbus consolekit provide net }
Need to check with upstream as consolekit exposes a dbus service and networkmanager should be able to find it whenever it starts.
(In reply to Gilles Dartiguelongue from comment #18) > Need to check with upstream as consolekit exposes a dbus service and > networkmanager should be able to find it whenever it starts. i think that's the problem. if consolekit isn't found at startup it won't use it. You can reproduce it: #remove consolekit from the default runlevel rc-update del consolekit default #add Networkmanager to the default runlevel rc-update add NetworkManager default #reboot pc reboot #after bootup with xdm/sddm no login by now, consolekit is now up but not started from the initscript /etc/init.d/consolekit status * status: stopped ps aux|grep console root 3856 0.0 0.0 408520 5920 ? Sl 18:52 0:00 /usr/sbin/console-kit-daemon --no-daemon so consolekit is started by xdm/sddm but not as initscript dependency, xdm only has a use dep: grep "use.*consolekit" /etc/init.d/* /etc/init.d/xdm: use consolekit dbus xfs and after the login of the user the networkconnection marked with "Automatically connect to this network when it's available" but not with "All users may connect to this network" isn't automatically borught up. although restarting networkamanger (/etc/init.d/netowrkmanger restart) brings up the connections directly after the restart of nm automatically. the workaround i proposed before isn't correct as removing networkamanger from the default runlevel is no good idea and could still lead to race conditions, instead the consolekit should be a needed dep in the networkmanagers init script when networkanager was compiled with the consolekit useflag depend() { need dbus consolekit provide net }
> and after the login of the user the networkconnection marked with > "Automatically connect to this network when it's available" but not with > "All users may connect to this network" isn't automatically borught up. > although restarting networkamanger (/etc/init.d/netowrkmanger restart) > brings up the connections directly after the restart of nm automatically. > btw. the networkconnection only comes up automatically after the manual restart, when the patch "[PATCH 2/2] session-monitor: fix parsing of ConsoleKit database" is applied
(In reply to Herbert Wantesh from comment #17) > maybe someone should add consolekit as "need" to the Networkmanager init > script when the consolekit > useflag is set, to avoid Networkmanager getting started before consolekit > like: > > /etc/init.d/NetworkManager: > > depend() { > need dbus consolekit > provide net > } That does indeed work for me: clevow230ss fitzcarraldo # rc-update show -v | grep NetworkManager NetworkManager | default clevow230ss fitzcarraldo # head -n 12 /etc/init.d/NetworkManager #!/sbin/openrc-run # Copyright (c) 2008 Saleem Abdulrasool <compnerd@compnerd.org> # Distributed under the terms of the GNU General Purpose License v2 # $Id$ description="NetworkManager daemon. The service is marked as started only \ when a network connection is established." depend() { need dbus consolekit provide net } clevow230ss fitzcarraldo # rc-status Runlevel: default dbus [ started ] syslog-ng [ started ] consolekit [ started ] NetworkManager [ started ] netmount [ started ] cupsd [ started ] samba [ started ] cronie [ started ] clamd [ started ] bluetooth [ started ] xdm [ started ] cups-browsed [ started ] sshd [ started ] local [ started ] Dynamic Runlevel: hotplugged Dynamic Runlevel: needed/wanted modules-load [ started ] xdm-setup [ started ] avahi-daemon [ started ] Dynamic Runlevel: manual ntp-client [ started ]
any updates? why isn't this merged by now?
I have the same issue. The consolekit workaround does not work for me.
you need the workaround and the mentioned patch
Please increase the priority of this bug as it affects stable desktop users.
should be ok in 1.4.4
(In reply to Pacho Ramos from comment #26) > should be ok in 1.4.4 I have quickly tested this version and confirm that the bug is fixed. Please mark it for a quick stabilization in your list. This is one of main functionality of any network manager which should work by default
In my case networkmanager-1.4.4 only automatically activates connections marked with "Automatically connect to this network when it's available" if the init script also has 'need consolekit' as follows: depend() { need dbus consolekit provide net } So 1.4.4 alone does not fix the problem in my case.
(In reply to Fitzcarraldo from comment #28) > In my case networkmanager-1.4.4 only automatically activates connections > marked with "Automatically connect to this network when it's available" if > the init script also has 'need consolekit' as follows: > > depend() { > need dbus consolekit > provide net > } > > So 1.4.4 alone does not fix the problem in my case. Can you try with "use dbus consolekit" instead of "need"? Otherwise we would need to force people to choose between either systemd or consolekit (now the ebuild is supposedly allowing setups without both... but I am not sure how is that working really)
(In reply to Pacho Ramos from comment #29) > (In reply to Fitzcarraldo from comment #28) > > In my case networkmanager-1.4.4 only automatically activates connections > > marked with "Automatically connect to this network when it's available" if > > the init script also has 'need consolekit' as follows: > > > > depend() { > > need dbus consolekit > > provide net > > } > > > > So 1.4.4 alone does not fix the problem in my case. > > Can you try with "use dbus consolekit" instead of "need"? Otherwise we would > need to force people to choose between either systemd or consolekit (now the > ebuild is supposedly allowing setups without both... but I am not sure how > is that working really) "use dbus consolekit" seems to work for me. but as the bug is a race condition as networkmanager is sometimes started before consolekit and it doesn't recognice it, if it isn't up before networkmanager is started, i will test "use dbus consolekit" and report back if it really works reliable
(In reply to Pacho Ramos from comment #29) > (In reply to Fitzcarraldo from comment #28) > > In my case networkmanager-1.4.4 only automatically activates connections > > marked with "Automatically connect to this network when it's available" if > > the init script also has 'need consolekit' as follows: > > > > depend() { > > need dbus consolekit > > provide net > > } > > > > So 1.4.4 alone does not fix the problem in my case. > > Can you try with "use dbus consolekit" instead of "need"? Otherwise we would > need to force people to choose between either systemd or consolekit (now the > ebuild is supposedly allowing setups without both... but I am not sure how > is that working really) I have changed "need dbus consolekit" to "use dbus consolekit" and rebooted six times so far, and the NetworkManager service has always started after the dbus and consolekit services, so it is looking promising, but I need to try rebooting a lot more before I can be confident the problem has been resolved (in my case at least). May I recommend that "RESOLVED FIXED" is reverted to "IN_PROGRESS", as a fix is still unresolved?
[master ea79859] net-misc/networkmanager: Try to use consolekit service if built with that support to prevent race conditions (#595806) 2 files changed, 400 insertions(+) create mode 100644 net-misc/networkmanager/files/init.d.NetworkManager-r1 create mode 100644 net-misc/networkmanager/networkmanager-1.4.4-r1.ebuild
(In reply to Pacho Ramos from comment #32) > [master ea79859] net-misc/networkmanager: Try to use consolekit service if > built with that support to prevent race conditions (#595806) > 2 files changed, 400 insertions(+) > create mode 100644 net-misc/networkmanager/files/init.d.NetworkManager-r1 > create mode 100644 net-misc/networkmanager/networkmanager-1.4.4-r1.ebuild I merged 1.4.4-r1 and have rebooted many times since then, and the change looks to have solved the problem. The NetworkManager service always starts after the dbus and consolekit services have started (NetworkManager is always the next service to start after consolekit in my installation). So I believe the bug has been squashed. Thanks.
for me too
