Systemd-networkd does not work


I would like to use systemd-networkd.service instead of using networking.service.

I disabled networking.service by “systemctl disable networking.service”, and enabled systemd-networkd.service by
“systemctl enable systemd-networkd.service”.

I removed /etc/network/interfaces and /etc/network/interfaces.d/*
Then I created /etc/systemd/network/ of permission 644 with the following contents:


Then I reboot system.
eth0 got an dhcp IPv4 address. And I can initially ping it from my laptop. However, after about 1 minute, ping failed. I then restart systemd-networkd.service, but this time, eth0 didn’t get any DHCP IPv4 address.

I also tried put “DHCP=ipv4” in network file, but it still failed.

Why it initially works, but after 1 minute, it lose network connection?



Thanks for reporting this.
We will check it and update more information with you later.


Hi Shuo,

Could you confirm the status of systemd-networkd from systemctl. Also, what is the result from “ifconfig”?

You could also debug with the syslog first to see why it goes down.

The status of systemd-networkd is active and SUCCESS. There is no error in systemd-networkd status.
Also, there is no error or goes down logs for eth0.

As I said, ifconfig shows an DHCP address on eth0. And I can ping this IP initially. But after 30 seconds to 1 minute, I couldn’t ping it anymore.

After that if I restart systemd-networkd, it won’t get any DHCP IP address on eth0. But systemd-networkd has no error in its status. And there is no error or goes down message in syslog either.


Does up/down the interface help your case? Also, is the content in #1 the full service code?
What is your purpose to write your own service for dhcp?

No, up/down interface doesn’t help.
The content in #1 is the systemd-networkd config file for an interface. It is not the service file.
Basically, when systemd-networkd service starts up, it read all your network interface config file under /etc/systemd/network/

NetworkManager might be getting in the way. You may want to poke around with the “nm-connection-editor” and see if anything there sticks out.

There is no NetworkManager running. There is even no NetworkManager service file which starts it.
nm-connection-editor shows:
Unable to init server: Could not connect: Connection refused
(nm-connection-editor:14734): Gtk-WARNING **: 12:02:05.161: cannot open display:

I think it means there is no NetworkManager running.

I agree, that means NM can’t be getting in the way. I couldn’t tell you though why the systemd method is not working, I have not tried to set it up that way. If I had that unit, then what I’d do is try to break down the commands systemd actually uses and see if the manual operation of those commands works.

If you can monitor “dmesg --follow” early on, and then see any log messages during the change to failure it might offer some clues. You might also compare an early “ifconfig” and “route” output, then compare to the after-failure case of “ifconfig” and “route”.

I would like to reproduce this issue on my devkit too.
Could you share the full steps again? I am not sure if #1 is the full one.

Also, sorry that I am not very familiar with these services here. Just share my current understanding here…
According to this service would use a binary “systemd-networkd” to read your config to manage the network interface.

I guess this binary may have something wrong since our normal network management does not use it.

  1. create /etc/systemd/network/ with the following contents:


  1. chmod 644 /etc/systemd/network/
  2. systemctl disable networking.service
  3. systemctl enable systemd-networkd.service
  4. removed /etc/network/interfaces and /etc/network/interfaces.d/* (better to back them up in a directory)
  5. reboot your system by “reboot”

Here is a good tutorial:


Most likely it is caused by an issue in systemd-networkd. And the traditional networking service satisfies my needs. So I will mark your answer as “Solution”.


We are still debugging why systemd-networkd would hit this issue. Will update this thread once we find something.

Please check if this helps:

When the issue happens, we still see MAC receiving packets. Looks to be an issue in the service.

1 Like