Troubleshooting “RTNETLINK answers: File exists” Error When Starting Network Service in CentOS 7 After NetworkManager Removal


1 views

When attempting to switch from NetworkManager to traditional network service in CentOS 7, many administrators encounter this persistent error:

RTNETLINK answers: File exists
network.service: control process exited, code=exited status=1
Failed to start LSB: Bring up/down networking

The "File exists" error typically occurs when there are residual network configurations or interface conflicts after removing NetworkManager. The key factors are:

  • Network interface state mismanagement
  • Conflicting DHCP client processes
  • Improper service removal sequence
  • Residual configuration files

Step 1: Clean Up Residual Processes

First, ensure all network-related processes are terminated properly:

# Stop all networking services
sudo systemctl stop network
sudo pkill dhclient
sudo pkill NetworkManager

# Verify no remaining processes
ps aux | grep -E 'network|dhclient|NetworkManager'

Step 2: Reset Network Interface

Forcefully bring down the interface and clear any existing configurations:

# Bring interface down
sudo ip link set enp8s0 down

# Remove all IP addresses
sudo ip addr flush dev enp8s0

# Delete any existing routes
sudo ip route flush dev enp8s0

Step 3: Reconfigure Network Scripts

Modify your interface configuration file (/etc/sysconfig/network-scripts/ifcfg-enp8s0):

# Recommended minimal configuration
TYPE=Ethernet
BOOTPROTO=dhcp
NAME=enp8s0
DEVICE=enp8s0
ONBOOT=yes
NM_CONTROLLED=no

Step 4: Refresh Network Configuration

Apply the changes and restart services:

# Remove DHCP leases
sudo rm -f /var/lib/dhclient/*.lease

# Restart network service
sudo systemctl restart network

# Enable persistent service
sudo systemctl enable network

For environments where complete NetworkManager removal isn't necessary:

# Reinstall NetworkManager but disable it
sudo yum install NetworkManager
sudo systemctl disable NetworkManager
sudo systemctl enable network

After implementing the solution, verify proper functionality:

# Check interface status
ip addr show enp8s0

# Test network connectivity
ping -c 4 google.com

# Verify service status
systemctl status network.service

After removing NetworkManager in CentOS 7 and trying to start the traditional network service, you might encounter the frustrating "RTNETLINK answers: File exists" error. This typically occurs when there are conflicts in network interface configurations or when legacy network components aren't properly cleaned up.

The error message suggests that the system is trying to create network routes or interfaces that already exist. This can happen when:

  • NetworkManager wasn't completely removed or left artifacts
  • Interface configuration files contain duplicate entries
  • DHCP client is running concurrently with static configurations
  • Network scripts are trying to re-create existing routes

Here's how to systematically resolve this issue:

1. Clean Up Network Artifacts

First, ensure all NetworkManager components are properly removed:

# yum remove NetworkManager -y
# rm -rf /etc/NetworkManager

2. Verify Interface Configuration

Check your interface configuration file (e.g., /etc/sysconfig/network-scripts/ifcfg-enp8s0):

TYPE=Ethernet
BOOTPROTO=dhcp
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
NAME=enp8s0
ONBOOT=yes

3. Stop All Network Services

Bring down all network interfaces before making changes:

# systemctl stop network
# ip link set enp8s0 down

4. Clear Existing Routes and ARP Cache

Remove any existing network configurations:

# ip route flush dev enp8s0
# ip neigh flush dev enp8s0

5. Restart Network Services

Now try restarting the network service:

# systemctl start network
# systemctl enable network

If the above doesn't work, try recreating the network service configuration:

# mv /etc/sysconfig/network-scripts/ifcfg-enp8s0 /root/ifcfg-enp8s0.bak
# systemctl restart network
# nmcli device connect enp8s0

For more detailed troubleshooting:

# journalctl -xe
# cat /var/log/messages | grep network
# dmesg | grep -i eth

After resolving the issue, verify your network connectivity:

# ping google.com
# ip addr show
# route -n