Why does the systemd network.service complain about "Could not load file '/etc/sysconfig/network-scripts/ifcfg-lo'"

Question

I have several brand new CentOS 7 systems which I installed using Kickstart.

When I restart the network, I notice strange errors which say "Could not load file '/etc/sysconfig/network-scripts/ifcfg-lo'". This error doesn't really make sense, because the ifcfg-lo file exists, and it looks normal to me. The system seems to be functioning normally, so why is the Network service complaining?

[root@host3 ~]# cat /etc/sysconfig/network-scripts/ifcfg-lo 
DEVICE=lo
IPADDR=127.0.0.1
NETMASK=255.0.0.0
NETWORK=127.0.0.0
# If you're having problems with gated making 127.0.0.0/8 a martian,
# you can change this to something else (255.255.255.255, for example)
BROADCAST=127.255.255.255
ONBOOT=yes
NAME=loopback
[root@host3 ~]#


[root@host3 ~]# systemctl restart network
[root@host3 ~]# journalctl -xe -u network.service
...
-- Subject: Unit network.service has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit network.service has begun starting up.
Sep 30 15:02:56 host3.example.org network[36432]: Bringing up loopback interface:  Could not load file '/etc/sysconfig/network-scripts/ifcfg-lo'
Sep 30 15:02:56 host3.example.org network[36432]: Could not load file '/etc/sysconfig/network-scripts/ifcfg-lo'
Sep 30 15:02:56 host3.example.org network[36432]: Could not load file '/etc/sysconfig/network-scripts/ifcfg-lo'
Sep 30 15:02:56 host3.example.org network[36432]: Could not load file '/etc/sysconfig/network-scripts/ifcfg-lo'
Sep 30 15:02:56 host3.example.org network[36432]: [  OK  ]
Sep 30 15:02:56 host3.example.org network[36432]: Bringing up interface eth0:  Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/3)
Sep 30 15:02:56 host3.example.org network[36432]: [  OK  ]
Sep 30 15:02:56 host3.example.org systemd[1]: Started LSB: Bring up/down networking.
-- Subject: Unit network.service has finished start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit network.service has finished starting up.
-- 
-- The start-up result is done.
[root@host3 ~]#

Update responding to @SmallLoanOf1M's question. The actual device seems to be up and running after boot. The 'UNKNOWN' field seems to be normal, as far as I can tell.

[root@host3 ~]# ip addr show dev lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
[root@host3 ~]#

Solution

This is currently being tracked as a bug by Red Hat, see this knowledge article.

Fix: Add NM_CONTROLLED=no to /etc/sysconfig/network-scripts/ifcfg-lo.

Root Cause: ifcfg-rh plugin in NetworkManager does not support loopback interface type and logs a message about it in system log.

Comments

[Admin]

Question: is the loopback interface up and working after boot? That should be created by the kernel, and modified by the ifcfg-lo file if need be. You should be able to see a loopback interface with no ifcfg-lo file at all.

[Admin]

Hi @SmallLoanOf1M Yes, the loopback interface seems to be working after boot.

[Admin]

Well, the messages about not being able to load the ifcfg-lo file are potentially trash - buy why? Researching, I see that this is fairly common, but don't see any concrete reason as to why it's happening. However, NetworkManager seem to be involved each time. It would be entirely unsurprising if NM was causing a fuss here.

[Admin]

From what I've read about NM on RHEL7, from several RHEL support engineers, is that NM doesn't suck this time around. I just need to figure out how to implement it properly.

[Admin]

Could be caused by the lack of the NM_CONTROLLED parameter, perhaps. But if that's the case, why doesn't CentOS 7 add this parameter by default? All I did was kickstart the system.

[Stefan Lasiewski]

Cool, thanks. Technically, I'm not sure this is a bug, as the KB doesn't refer to it as a bug and simply recommends a workaround.