Bug 1371370

Description of problem:

# systemctl restart network - does not work as expected. If the network service is running, restarting it will result in failure, and if the network service is in failed state, restarting it will bring up the service. Moreover reboot of the system does not bring up network service.

Note : Since exact component could not be selected for reporting this issue, the chosen one may not be matching.

Version-Release number of selected component (if applicable):

# rpm -q --qf "Name=%{name}\nVersion=%{version}\nRelease=%{release}\nArch=%{arch}\n" $(rpm -qf /etc/rc.d/init.d/network)
Name=initscripts
Version=9.65
Release=2.fc24
Arch=x86_64


How reproducible: Frequently


Steps to Reproduce:
1. # systemctl restart network or reboot
2.
3.

Actual results:

network: failed.
network: [FAILED]
systemd: network.service: Unit entered failed state.

Expected results:

should be up and running.


Additional info:

Fedora forum Link : http://forums.fedoraforum.org/showthread.php?p=1769736#post1769736

======= Information =======

t is a wired network, and the link is present. But the network service is not working as expected.

When the network service is "restarted", it should shutdown the interfaces and bring it back normally even if the IP has to be fetched from a DHCP source. But it does not happen.

1. restart the network service. The primary interface does not come up, but it is all wired. No issues with the physical link, and the interface can be brought up manually.

# systemctl restart network
Job for network.service failed because the control process exited with error code. See "systemctl status network.service" and "journalctl -xe" for details.

--- logs ---
network: Shutting down interface enp5s0: [ OK ]
network: Shutting down interface pubnet: [ OK ]
network: Shutting down loopback interface: [ OK ]
systemd: Stopped LSB: Bring up/down networking.
audit: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=network comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
network: Bringing up loopback interface: [ OK ]
network: Bringing up interface enp5s0:
network: Determining IP information for enp5s0... failed; no link present. Check cable? < cable is present. No issues with physical connectivity
network: [FAILED]
network: Bringing up interface pubnet: [ OK ]
systemd: network.service: Control process exited, code=exited status=1
systemd: Failed to start LSB: Bring up/down networking.
systemd: network.service: Unit entered failed state.

2. Dhclient process does not run.

# ps -eo comm,pid | grep -i ^dhclient < No output

3. Bringing up interface manually

# ifup enp5s0

Determining IP information for enp5s0... done. < interface is up

# ps -eo comm,pid | grep -i ^dhclient
dhclient 907

dhclient process also runs now.

4. But still the network status is in "failed state". Attempting to restart the network service again, does not succeed because network service points to a different problem for not coming up cleanly.

# systemctl restart network
Job for network.service failed because the control process exited with error code. See "systemctl status network.service" and "journalctl -xe" for details.

But dhclient process is still running.

# ps -eo comm,pid | grep -i ^dhclient
dhclient 907

Since "dhclient" process is running the "network" service fail to come up properly when it was restarted.   < Seems like a bug >

IP is still assigned to the interface, even when the overall network status is in "failed" state.

# ip a s enp5s0
2: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether bc:ae:c5:30:94:06 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.13/24 brd 192.168.0.255 scope global dynamic enp5s0
valid_lft 3586sec preferred_lft 3586sec

--- Reason for failure, from logs ---

network: Bringing up loopback interface: [ OK ]
network: Bringing up interface enp5s0:
network: Determining IP information for enp5s0...dhclient(907) is already running - exiting.
network: This version of ISC DHCP is based on the release available
network: on ftp.isc.org. Features have been added and other changes
network: have been made to the base software release in order to make
network: it work better with this distribution.
network: Please report for this software via the Red Hat Bugzilla site:
network: http://bugzilla.redhat.com
network: exiting.
network: failed.
network: [FAILED]
systemd: network.service: Unit entered failed state.

5. Now kill the dhclient process.

# pkill dhclient

6. restart the network service. This time it comes up cleanly.

systemd: Stopped LSB: Bring up/down networking.
systemd: Starting LSB: Bring up/down networking...
network: Bringing up loopback interface: [ OK ]
network: Bringing up interface enp5s0:
network: Determining IP information for enp5s0... done.
network: RTNETLINK answers: File exists
network: [ OK ]
network: Bringing up interface pubnet: [ OK ]
network: RTNETLINK answers: File exists
network: RTNETLINK answers: File exists
network: RTNETLINK answers: File exists
network: RTNETLINK answers: File exists
network: RTNETLINK answers: File exists
network: RTNETLINK answers: File exists
network: RTNETLINK answers: File exists
network: RTNETLINK answers: File exists
network: RTNETLINK answers: File exists
systemd: Started LSB: Bring up/down networking.

dhclient process also runs now.

# ps -eo comm,pid | grep -i ^dhclient
dhclient 1743


Hence, this line below;

Determining IP information for enp5s0... failed; no link present. Check cable?

is not specific message, since there was no issues with cable or H/W. This message actually does not help in proper troubleshooting.

The whole process restarting of network service seems not to be working the way it should be.

> The "dhclient" process needs to be killed in order for it to come up cleanly.
> If the interface is brought up manually, the overall status of the network service is still in "failed" state.
> When the network service is up and running, enters into "failed" state once it is restarted. This is not expected out of any service.

Hence, it would be highly appreciable if this behavior of "network" service can be investigated in-depth and probably make some fixes so that it becomes more reliable and predictable, until NetworkManager is mature enough to support "not only native bridges", but also "openvswitch".