Not a problem; just a systemd query

Linux Support
1

I have recently been getting an error upon booting my Dell Latitude E5570 that says something like

Daemon failed to start systemd networkd

… but everything appears to be working normally. I tried:

keith@E5570:~$ systemctl status systemd-networkd
○ systemd-networkd.service - Network Configuration
Loaded: loaded (/lib/systemd/system/systemd-networkd.service; disabled; vendor preset: enabled)
Active: inactive (dead)
TriggeredBy: ○ systemd-networkd.socket
Docs: man:systemd-networkd.service(8)
keith@E5570:~$

…which seems to indicate that something is not happy. Although I have no immediate problems it would be interesting to know what’s going on if anyone would care to comment.

Keith

2

Yeah, networking can be fun :scream: , there are many ways to configure networking on your machine, these have changed a lot over the years. The new default on Ubuntu seems to be to use something called “netplan”, so on a clean machine you should find something like; /etc/netplan/00-installer-config.yaml

# This is the network config written by 'subiquity'
network:
  ethernets:
    enp1s0:
      dhcp4: true
  version: 2

Which results in an interface that presents as;

enp1s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.186  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::5054:ff:fe84:ee2c  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:84:ee:2c  txqueuelen 1000  (Ethernet)
        RX packets 16328837  bytes 94046401221 (94.0 GB)
        RX errors 0  dropped 1  overruns 0  frame 0
        TX packets 13001749  bytes 27009796547 (27.0 GB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

And when you run your systemd status command you get;

● systemd-networkd.service - Network Configuration
     Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled; preset: enabled)
     Active: active (running) since Mon 2023-10-16 15:22:25 UTC; 1 week 2 days ago
TriggeredBy: ● systemd-networkd.socket
       Docs: man:systemd-networkd.service(8)
   Main PID: 918 (systemd-network)
     Status: "Processing requests..."
      Tasks: 1 (limit: 6779)
     Memory: 1.1M
        CPU: 1.669s
     CGroup: /system.slice/systemd-networkd.service
             └─918 /lib/systemd/systemd-networkd

Now on my machine, I too get the same report as you do, the reason I get this message is because my network configuration pre-dates netplan and as a result it’s only partially managed by Networkmanager.

Also, my main interface is configured as a Bridge so any virtual machines I configure are presented directly on my LAN, however this is a “why” I have a custom config, not necessarily linked to your “why”. Essentially, for some reason, you appear to have a custom config.

Useful files;

  • /etc/NetworkManager/NetworkManager.conf
[ifupdown]
managed=false
  • /etc/NetworkManager/system-connections
    Typically in this folder, if it’s in use, one file per interface. Standard INI format, detailing the interface, dns lookup options, etc.

So … if I was feeling brave I might delete the .conf and system connection files, create a netplan that describes my bridge setup, then reboot. However, a fully managed interface / bridge doesn’t necessarily give me anything new … so in the spirit of “if it ain’t broke …”, for now I’ll leave it alone :slight_smile:

3

Well, although I don’t understand much of your description, I am somewhat relieved that my system appears to be OK, based on your examples.

For interest, here’s some output:

keith@E5570:~$ ls /etc/netplan/00-installer-config.yaml
ls: cannot access ‘/etc/netplan/00-installer-config.yaml’: No such file or directory
keith@E5570:~$ cat /etc/NetworkManager/NetworkManager.conf
[main]
plugins=ifupdown,keyfile

[ifupdown]
managed=false

[device]
wifi.scan-rand-mac-address=no
keith@E5570:~$ ls /etc/NetworkManager/system-connections
BTWholeHome-FV3.nmconnection nl-free-67.protonvpn.net.udp.nmconnection VM0856052.nmconnection
EE-Hub-k3En.nmconnection TALKTALK74007F.nmconnection
keith@E5570:~$

Interesting to see the reference to nl-free-67.protonvpn.net.udp.nmconnection which is a Proton VPN server in the Netherlands, although I have uninstalled ProtonVPN (or thought I had). But that’s another story!

Thanks, MP.

4

Well, there are other ways (depending on your flavour of Linux) to set up networking, but the “managed=false” is probably the key indicator. If you do an “ifconfig” and extract the name of your network interface (for example “enp1s0”, or on older systems, something like “eth0”) then do;

find /etc -exec grep -Hi enp1s0 {} \; 2>/dev/null

It might give you some indication as to what is handling your config … historically maybe something like; /etc/network/interfaces

5

The first part of ifconfig is

keith@E5570:~$ ifconfig
enp0s31f6: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether 84:7b:eb:0c:4f:f9 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 16 memory 0xe1300000-e1320000

then:

keith@E5570:~$ find /etc -exec grep -Hi enp0s31f6 {} ; 2>/dev/null
keith@E5570:~$

and:

keith@E5570:~$ ls /etc/network/interfaces
ls: cannot access ‘/etc/network/interfaces’: No such file or directory
keith@E5570:~$

which is probably not very helpful.

6

Mm, ok, try this;

sudo find /etc/ -type f -exec grep -Hi enp0s31f6 {} \;

Explaination: the previous command was me being a little lazy, without “-type f” it will try to grep directories, which will generate errors. Instead of checking the syntax of “-type f” and only searching files, I was just dumping errors with 2>/dev/null … which would hide permission denied errors too …

7

keith@E5570:~$ sudo find /etc/ -type f -exec grep -Hi enp0s31f6 {} ;
[sudo] password for keith:
keith@E5570:~$

Still no joy. A bit like life, really.

8

Ok, so …

I reckon my laptop was in the same state as yours, it appears that when “NetworkManager” is managing your network devices, the configuration is hidden in some way, at least I’m not seeing where it stores settings “under the hood”.

It would appear there are now two main options for “managing” network connections, the first (older) mechanism is “NetworkManager”, which is a desktop oriented framework which is maybe a little heavier than server-types appreciate. (which comes with GUI’s etc etc) Then there is the new preferred option which seems to be “netplan”, which is a move back towards config files and “separate” GUI’s. (which to me seems way more sensible, if I understand things correctly)

I think as of 23.10 everything is “netplan”, prior, we appear to have a mish-mash going back to 18.04.

Just to get an understanding, I’ve moved my laptop over so “netplan” is the network manager of choice. Everything still “seems” to work and my laptop is set up with bridges and LXD containers, so it doesn’t looks to be a destructive process.

What I did;

  • Ensure there is one file in /etc/netplan, I had one called 01-network-manager-all.yaml, you probably have one and it’s the “renderer” line that makes the difference. Yours is probably set to “NetworkManager”. (take copies of existing files in this folder, just in case)
  • In the config file, ensure the renderer is set to networkd
  • Also ensure the devices you wish to manage are listed, you don’t need to add WiFi or LXD connections, these will just work anyway.
  • Ensure the files permissions are 0x600 (owner access only)

This should be what you want;

network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s31f6:
      addresses: []
      dhcp4: true

You can test it with;

netplan try

If this takes, netplan apply will write it.
Assuming all is well, a reboot should finish it off, just to be sure.

After a reboot, netplan status should tell you what’s going on, and your “systemctl” command should now report the status of your ethernet port :slight_smile:

$ netplan status
     Online state: online
    DNS Addresses: 127.0.0.53 (stub)
       DNS Search: home

●  2: enp19s0 ethernet UP (networkd: enp19s0)
      MAC Address: f0:bf:97:04:bc:87 (Realtek Semiconductor Co., Ltd.)
        Addresses: 192.168.1.138/24 (dhcp)
                   2a00:23c7:3c40:ce01:f2bf:97ff:fe04:bc87/64
                   fe80::f2bf:97ff:fe04:bc87/64 (link)
    DNS Addresses: 192.168.1.254
                   fe80::f286:20ff:fe5e:98b6
       DNS Search: home
           Routes: default via 192.168.1.254 from 192.168.1.138 metric 100 (dhcp)
                   192.168.1.0/24 from 192.168.1.138 metric 100 (link)
                   192.168.1.254 from 192.168.1.138 metric 100 (dhcp, link)
                   2a00:23c7:3c40:ce01::/64 metric 100 (ra)
                   fe80::/64 metric 256
                   default via fe80::f286:20ff:fe5e:98b6 metric 100 (ra)

$ sudo systemctl status systemd-networkd
● systemd-networkd.service - Network Configuration
     Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled-runtime; preset: enabled)
     Active: active (running) since Fri 2023-10-27 12:17:27 BST; 22min ago
TriggeredBy: ● systemd-networkd.socket
       Docs: man:systemd-networkd.service(8)
   Main PID: 949 (systemd-network)
     Status: "Processing requests..."
      Tasks: 1 (limit: 6989)
     Memory: 3.6M
        CPU: 237ms
     CGroup: /system.slice/systemd-networkd.service
             └─949 /lib/systemd/systemd-networkd

Oct 27 12:20:13 spartan systemd-networkd[949]: vetha4cf3740: Lost carrier
Oct 27 12:20:13 spartan systemd-networkd[949]: physNSSNPW: Interface name change detected, renamed to veth4b63d>
Oct 27 12:20:13 spartan systemd-networkd[949]: vetha4cf3740: Link UP
Oct 27 12:20:13 spartan systemd-networkd[949]: vetha4cf3740: Link DOWN
Oct 27 12:20:14 spartan systemd-networkd[949]: lxdbr0: Lost carrier
Oct 27 12:21:12 spartan systemd-networkd[949]: wlp7s0: Connected WiFi access point: BT-2FA6HK (f0:86:20:5e:98:b>
9

keith@E5570:~$ ls /etc/netplan
01-network-manager-all.yaml
keith@E5570:~$ cat /etc/netplan/01-network-manager-all.yaml
“#” Let NetworkManager manage all devices on this system
network:
version: 2
renderer: NetworkManager
keith@E5570:~$ sudo gedit /etc/netplan/01-network-manager-all.yaml

So far so good and I changed Network Manager to networkd and saved. But then you say:

  • Also ensure the devices you wish to manage are listed, you don’t need to add WiFi or LXD connections, these will just work anyway.
  • Ensure the files permissions are 0x600 (owner access only)

But where do I do this? Sorry to be dim, but it’s not obvious.

10

Ok, so unless you know you want to manage something else, ignore the first. For the second;

chmod 600 /etc/netplan/01-network-manager-all.yaml

Or, of you’re happier with the user, group, other nomenclature for permissions, with read, write, execute, then alternatively you could do;

chmod u=rw,g=,o= /etc/netplan/01-network-manager-all.yaml

hth

11

Note I’m assuming here you pasted this into the file (pre-tweaked with your interface name) as described above;

network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s31f6:
      addresses: []
      dhcp4: true
12

Oh, dear! I feel very foolish! Of course I know how to change permissions. Must be an age thing. But I didn’t realise I had to replace the file contents which I have done now.
But then:

keith@E5570:~$ netplan try
Traceback (most recent call last):
File “/usr/sbin/netplan”, line 23, in
netplan.main()
File “/usr/share/netplan/netplan/cli/core.py”, line 48, in main
self.parse_args()
File “/usr/share/netplan/netplan/cli/core.py”, line 41, in parse_args
import netplan.cli.commands
File “/usr/share/netplan/netplan/cli/commands/init.py”, line 27, in
from netplan.cli.commands.status import NetplanStatus
File “/usr/share/netplan/netplan/cli/commands/status.py”, line 29, in
import dbus
ModuleNotFoundError: No module named 'dbus’
keith@E5570:~

Looks like an error?

13

Mm, well it looks like netplan is written in Python, and it looks like it’s a system tool, and it looks like it’s relying on the system installed Python libraries … and it looks like the dbus module is missing.

They want to use Python for system stuff, which is great, but they are going to have to sort this dependency issue at some point, it’s way too easy to break it.

See if;

apt install python3-dbus

Does anything for you, this seems to be the main package and it’s installed on my box. If this is installed properly, you should be able to do;

python3
import dbus

And not get an error … in which case netplan should work. Incidentally, netplan throwing an error like that could indicate some [other] stuff broken under the hood, so worth fixing.

14

The result:

keith@E5570:~$ sudo apt install python3-dbus
[sudo] password for keith:
Reading package lists… Done
Building dependency tree… Done
Reading state information… Done
python3-dbus is already the newest version (1.2.18-3build1).
python3-dbus set to manually installed.
0 to upgrade, 0 to newly install, 0 to remove and 18 not to upgrade.
keith@E5570:~$ python3
import dbus
Python 3.10.12 (main, Jun 11 2023, 05:26:28) [GCC 11.4.0] on linux
Type “help”, “copyright”, “credits” or “license” for more information.
“>>>”

It’s expecting me to type one of those options, none of which seem to be helpful here but might indicate that all is supposedly well?

15

Ah, i maybe spotted the problem. Did you run netplan as a user? To configure your machines networking you will need sudo?

16

No, I didn’t, but…

keith@E5570:~$ sudo netplan try
[sudo] password for keith:
Traceback (most recent call last):
File “/usr/sbin/netplan”, line 23, in
netplan.main()
File “/usr/share/netplan/netplan/cli/core.py”, line 48, in main
self.parse_args()
File “/usr/share/netplan/netplan/cli/core.py”, line 41, in parse_args
import netplan.cli.commands
File “/usr/share/netplan/netplan/cli/commands/init.py”, line 27, in
from netplan.cli.commands.status import NetplanStatus
File “/usr/share/netplan/netplan/cli/commands/status.py”, line 29, in
import dbus
ModuleNotFoundError: No module named ‘dbus’
keith@E5570:~$

…looks the same.

17

It does. But if you can import dbus, its there, so something looks seriously borked. So to fix this the next thing I would try would be to apt remove --purge netplan , then try adding it again.

However, Im not sure what this will do to the system and whether it will let you re add without some manual intervention - so you may not want to do this.

I’ve not seen netplan malfunction before, but then I guess it’s still relatively new. Not sure what else to suggest atm unless you want to give me remote access so I can see where Python is going wrong …