Bug 1077913 - NetworkManager being activated unexpectedly after last update
NetworkManager being activated unexpectedly after last update
Status: RESOLVED INVALID
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Network
Current
Other Other
: P5 - None : Critical with 1 vote (vote)
: ---
Assigned To: openSUSE GNOME
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-01-29 07:26 UTC by Silviu Marin-Caea
Modified: 2018-08-20 05:52 UTC (History)
2 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Silviu Marin-Caea 2018-01-29 07:26:43 UTC
I made a Tumbleweed update today 2018-01-29.

The computer fell into a network hole.

Two things happened:

1. NetworkManager service starts and steals focus from Wicked. Wicked was the configured service, but NM still starts even if it's not enabled:

09:14:23 silviupc:~ # systemctl status NetworkManager
● NetworkManager.service - Network Manager
   Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; disabled; vendor preset: disabled)
   Active: active (running)
     Docs: man:NetworkManager(8)
 Main PID: 844 (NetworkManager)
    Tasks: 5 (limit: 4915)
   CGroup: /system.slice/NetworkManager.service
           ├─ 844 /usr/sbin/NetworkManager --no-daemon
           └─2272 /sbin/dhclient -d -q -sf /usr/lib/nm-dhcp-helper -pf /var/run/dhclient-enp0s25.pid -lf /var/lib/NetworkManager/dhclient-dbcb2ae4-7bc3-379d-a1c9-aecd8ae2e7

Jan 29 09:14:15 silviupc.otpbank.ro NetworkManager[844]: <warn>  [1517210055.4809] device (enp0s25): Activation: failed for connection 'Wired connection 1'
Jan 29 09:14:15 silviupc.otpbank.ro NetworkManager[844]: <info>  [1517210055.4820] device (enp0s25): state change: failed -> disconnected (reason 'none', internal state 'ma
Jan 29 09:14:15 silviupc.otpbank.ro NetworkManager[844]: <info>  [1517210055.4914] policy: auto-activating connection 'Wired connection 1'
Jan 29 09:14:15 silviupc.otpbank.ro NetworkManager[844]: <info>  [1517210055.4927] device (enp0s25): Activation: starting connection 'Wired connection 1' (dbcb2ae4-7bc3-379
Jan 29 09:14:15 silviupc.otpbank.ro NetworkManager[844]: <info>  [1517210055.4930] device (enp0s25): state change: disconnected -> prepare (reason 'none', internal state 'm
Jan 29 09:14:15 silviupc.otpbank.ro NetworkManager[844]: <info>  [1517210055.4932] manager: NetworkManager state is now CONNECTING
Jan 29 09:14:15 silviupc.otpbank.ro NetworkManager[844]: <info>  [1517210055.4936] device (enp0s25): state change: prepare -> config (reason 'none', internal state 'managed
Jan 29 09:14:15 silviupc.otpbank.ro NetworkManager[844]: <info>  [1517210055.4941] device (enp0s25): state change: config -> ip-config (reason 'none', internal state 'manag
Jan 29 09:14:15 silviupc.otpbank.ro NetworkManager[844]: <info>  [1517210055.4944] dhcp4 (enp0s25): activation: beginning transaction (timeout in 45 seconds)
Jan 29 09:14:15 silviupc.otpbank.ro NetworkManager[844]: <info>  [1517210055.4954] dhcp4 (enp0s25): dhclient started with pid 2272

09:14:34 silviupc:~ # systemctl stop NetworkManager
09:14:40 silviupc:~ # systemctl restart network

2. The YaST LAN module does not work because it says it cannot load because:

Details: Failed to load Module 'Lan' due to: Failed to load Module 'LanItems' due to: cannot load such file - storage.

It's probably related to the new libstorage-ng. I'll open another bug report for this.


I don't understand why NM starts even if it's disabled.
Comment 1 Bernhard Seebass 2018-01-30 15:21:24 UTC
I can confirm this observation. I updated yesterday (2018-01-29) and today I noticed that I have two active IP addresses, one from fixed IP configuration and one from DHCP.

# ip addr show
...
    inet 192.168.10.203/24 brd 192.168.10.255 scope global dynamic enp0s31f6
       valid_lft 258994sec preferred_lft 258994sec
    inet 192.168.10.127/24 brd 192.168.10.255 scope global secondary enp0s31f6
       valid_lft forever preferred_lft forever


I had to manually stop NetworkManager and restart wicked to get rid of the dynamic ip address:
# systemctl stop NetworkManager 
# systemctl restart wicked
Comment 2 Silviu Marin-Caea 2018-02-07 10:37:20 UTC
Bug still alive after a fresh reinstall from Tumbleweed DVD snapshot.
Comment 3 Bernhard Seebass 2018-02-07 17:04:00 UTC
Workaround: use NetworkManager instead of Wicked (YaST2 Network Settings: Global Options).

Worked for me only after reinstalling NetworkManager. Before the reinstall NetworkManager still used DHCP, although configured otherwise.
Comment 4 Silviu Marin-Caea 2018-02-20 08:09:52 UTC
One more thing that I have noticed, might be related.

After reinstalling TW, the firewalld service was enabled by default. I specifically disable SUSE firewall during installation, but firewalld is a service of systemd that seems to be enabled by default and it's not taken into account by the installation system.

I'm trying to figure out what determines NetworkManager to start, it's some sort of dbus dependency, but I admit it's not something I understand right now.

Looks like both NetworkManager and wickedd have an alias network.service and both are dbus type. I don't know if that's a problem, how it's all supposed to work.

Maybe there was a new systemd version upgrade that changed default behavior, wants NetworkManager and overwritten some SUSE setting.
Comment 5 Jacob W 2018-02-21 14:46:58 UTC
About a year ago I had a similar problem after updating TW. Both NM and Wicked were fighting over who will manage my network connections (very prestigious managerial position). 

After seeking help on IRC, we came to the conclusion that NM should be managing the network on a desktop, wicked can be managing on a server. Never both. I disabled wicked.service and wickedd.service (I think YaST Network -> Global Settings had NM as default already). My network has been working great.
Comment 6 Silviu Marin-Caea 2018-04-30 12:29:42 UTC
Bug still alive, didn't expect it to have such a long life, seems like everybody is using only Network Manager on Tumbleweed.

BTW, I've seen that it's assigned to Gnome maintainers. For what it's worth, I'm using KDE.
Comment 7 Silviu Marin-Caea 2018-08-20 05:52:25 UTC
Mistery solved! Not SUSE's fault, but Teamviewer's.

Installing Teamviewer is activating Network Manager, because Teamviewer has this systemd unit:

cat /etc/systemd/system/teamviewerd.service

[Unit]
Description = TeamViewer remote control daemon
After = NetworkManager-wait-online.service network.target network-online.target dbus.service
Wants = NetworkManager-wait-online.service network-online.target
Requires = dbus.service

[Service]
Type = forking
PIDFile = /var/run/teamviewerd.pid
ExecStart = /opt/teamviewer/tv_bin/teamviewerd -d
Restart = on-abort
StartLimitInterval = 60
StartLimitBurst = 10

[Install]
WantedBy = multi-user.target

If I remove "NetworkManager-wait-online.service", all goes back to normal.