| Summary: | As root, "service network {start stop restart}" has no effect. | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Shlomi Fish <shlomif> |
| Component: | RPM Packages | Assignee: | Base system maintainers <basesystem> |
| Status: | RESOLVED WORKSFORME | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | bittwister2, lists.jjorge, marja11, tmb, zen25000 |
| Version: | Cauldron | ||
| Target Milestone: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | initscripts-9.78-5.mga7.src.rpm | CVE: | |
| Status comment: | |||
| Attachments: | The commands requested by bittwister | ||
are you using NetworkManager ? in that case it's expected.... CC:
(none) =>
tmb (In reply to Thomas Backlund from comment #1) > are you using NetworkManager ? > How do I tell if I am using it or not? > in that case it's expected.... What is the alternative? check status: systemctl status NetworkManager restart: systemctl status NetworkManager (In reply to Thomas Backlund from comment #3) > check status: > systemctl status NetworkManager > that showed it as inactive. > restart: > systemctl status NetworkManager start/stop of it has no effect either. And if you do systemctl restart network ?
Barry Jackson
2018-03-09 14:29:04 CET
CC:
(none) =>
zen25000 (In reply to Thomas Backlund from comment #5) > And if you do > > systemctl restart network ? root@telaviv1:~$ 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. root@telaviv1:~$ stop has no effect either. Same here from clean boot, I did have NM installed for some reason but was not using it. I uninstalled it and re-booted before this:
[baz@localhost ~]$ sudo systemctl status network.service
[sudo] password for baz:
● network.service - LSB: Bring up/down networking
Loaded: loaded (/etc/rc.d/init.d/network; generated; vendor preset: disabled)
Active: failed (Result: exit-code) since Fri 2018-03-09 13:50:55 GMT; 1min 20s ago
Docs: man:systemd-sysv-generator(8)
Process: 13735 ExecStart=/etc/rc.d/init.d/network start (code=exited, status=1/FAILURE)
CGroup: /system.slice/network.service
└─13928 /sbin/ifplugd -I -b -i enp2s0
Mar 09 13:50:55 localhost ifplugd(enp2s0)[13928]: Initialization complete, link beat detected.
Mar 09 13:50:55 localhost ifplugd(enp2s0)[13928]: Executing '/etc/ifplugd/ifplugd.action enp2s0 up'.
Mar 09 13:50:55 localhost network[13735]: Bringing up interface enp2s0: [ OK ]
Mar 09 13:50:55 localhost network[13735]: Bringing up interface wlan0: ERROR : [/etc/sysconfig/network-scripts/ifup-eth] usbcore devi>
Mar 09 13:50:55 localhost network[13735]: [FAILED]
Mar 09 13:50:55 localhost systemd[1]: network.service: Control process exited, code=exited status=1
Mar 09 13:50:55 localhost systemd[1]: network.service: Failed with result 'exit-code'.
Mar 09 13:50:55 localhost systemd[1]: Failed to start LSB: Bring up/down networking.
Mar 09 13:50:59 localhost ifplugd(enp2s0)[13928]: client: [ OK ]
Mar 09 13:50:59 localhost ifplugd(enp2s0)[13928]: Program executed successfully.
[baz@localhost ~]$ ping google.com
PING google.com (216.58.212.110) 56(84) bytes of data.
64 bytes from lhr35s06-in-f110.1e100.net (216.58.212.110): icmp_seq=1 ttl=54 time=22.9 ms
64 bytes from lhr35s06-in-f110.1e100.net (216.58.212.110): icmp_seq=2 ttl=54 time=23.3 ms
64 bytes from lhr35s06-in-f110.1e100.net (216.58.212.110): icmp_seq=3 ttl=54 time=23.4 ms
^C
--- google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 22.902/23.240/23.435/0.270 ms
[baz@localhost ~]$ sudo systemctl stop network.service
Note - no error message above but still connected:
[baz@localhost ~]$ ping google.com
PING google.com (172.217.23.46) 56(84) bytes of data.
64 bytes from lhr35s02-in-f46.1e100.net (172.217.23.46): icmp_seq=1 ttl=54 time=23.7 ms
64 bytes from lhr35s02-in-f46.1e100.net (172.217.23.46): icmp_seq=2 ttl=54 time=23.8 ms
64 bytes from lhr35s02-in-f46.1e100.net (172.217.23.46): icmp_seq=3 ttl=54 time=23.7 ms
^C
--- google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 23.781/23.811/23.870/0.182 ms
[baz@localhost ~]$ sudo systemctl restart network.service
Job for network.service failed because the control process exited with error code.
See "systemctl status network.service" and "journalctl -xe" for details.
[baz@localhost ~]$ sudo systemctl status network.service
● network.service - LSB: Bring up/down networking
Loaded: loaded (/etc/rc.d/init.d/network; generated; vendor preset: disabled)
Active: failed (Result: exit-code) since Fri 2018-03-09 13:53:31 GMT; 11s ago
Docs: man:systemd-sysv-generator(8)
Process: 23124 ExecStart=/etc/rc.d/init.d/network start (code=exited, status=1/FAILURE)
CGroup: /system.slice/network.service
└─13928 /sbin/ifplugd -I -b -i enp2s0
Mar 09 13:53:31 localhost network[23124]: RTNETLINK answers: File exists
Mar 09 13:53:31 localhost network[23124]: RTNETLINK answers: File exists
Mar 09 13:53:31 localhost network[23124]: RTNETLINK answers: File exists
Mar 09 13:53:31 localhost network[23124]: RTNETLINK answers: File exists
Mar 09 13:53:31 localhost network[23124]: RTNETLINK answers: File exists
Mar 09 13:53:31 localhost network[23124]: RTNETLINK answers: File exists
Mar 09 13:53:31 localhost network[23124]: RTNETLINK answers: File exists
Mar 09 13:53:31 localhost systemd[1]: network.service: Control process exited, code=exited status=1
Mar 09 13:53:31 localhost systemd[1]: network.service: Failed with result 'exit-code'.
Mar 09 13:53:31 localhost systemd[1]: Failed to start LSB: Bring up/down networking.
What should I read to understand this report (and to fix my network issue on laptop Assignee:
bugsquad =>
basesystem Shlomi never told us what the journal had to say about why network.service was failing. I don't know that it will impact the "no effect" issue, but check your /etc/sysconfig/network-scripts/ifcfg-* files and make sure there no backup files for any of the interfaces (*~ or *.bak or *.old, etc) and that the files for any interfaces you aren't using say ONBOOT=no inside of them. I've seen both of those issues cause network.service failures, especially on systemd systems like RHEL7 and newer versions of Mageia. (In reply to David Walser from comment #9) > Shlomi never told us what the journal had to say about why network.service > was failing. > here you go: <journal> Mar 15 18:22:16 telaviv1.shlomifish.org systemd[1]: network.service: Failed with result 'exit-code'. Mar 15 18:22:16 telaviv1.shlomifish.org systemd[1]: Failed to start LSB: Bring up/down networking. -- Subject: Unit network.service has failed -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit network.service has failed. -- -- The result is RESULT. Mar 15 18:22:46 telaviv1.shlomifish.org systemd[1]: network.service: Found left-over process 1450 (ifplugd) in control group while starting unit. Ignoring. Mar 15 18:22:46 telaviv1.shlomifish.org systemd[1]: This usually indicates unclean termination of a previous run, or service implementation deficiencies. Mar 15 18:22:46 telaviv1.shlomifish.org systemd[1]: network.service: Found left-over process 1618 (dhclient) in control group while starting unit. Ignoring. Mar 15 18:22:46 telaviv1.shlomifish.org systemd[1]: This usually indicates unclean termination of a previous run, or service implementation deficiencies. Mar 15 18:22:46 telaviv1.shlomifish.org systemd[1]: network.service: Found left-over process 31673 (ifplugd) in control group while starting unit. Ignoring. Mar 15 18:22:46 telaviv1.shlomifish.org systemd[1]: This usually indicates unclean termination of a previous run, or service implementation deficiencies. Mar 15 18:22:46 telaviv1.shlomifish.org systemd[1]: Starting LSB: Bring up/down networking... -- Subject: Unit network.service has begun start-up -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit network.service has begun starting up. Mar 15 18:22:46 telaviv1.shlomifish.org network[31749]: Bringing up loopback interface: [ OK ] Mar 15 18:22:47 telaviv1.shlomifish.org network[31749]: Bringing up interface enp0s29u1u5: ERROR : [/etc/sysconfig/network-scripts/ifup-eth] Device enp0s29u1u5 does not seem to be present, delaying initialization. Mar 15 18:22:47 telaviv1.shlomifish.org /etc/sysconfig/network-scripts/ifup-eth[31927]: Device enp0s29u1u5 does not seem to be present, delaying initialization. Mar 15 18:22:47 telaviv1.shlomifish.org network[31749]: [FAILED] Mar 15 18:22:47 telaviv1.shlomifish.org network[31749]: Bringing up interface enp3s0u2: ERROR : [/etc/sysconfig/network-scripts/ifup-eth] Device enp3s0u2 does not seem to be present, delaying initialization. Mar 15 18:22:47 telaviv1.shlomifish.org /etc/sysconfig/network-scripts/ifup-eth[31972]: Device enp3s0u2 does not seem to be present, delaying initialization. Mar 15 18:22:47 telaviv1.shlomifish.org network[31749]: [FAILED] Mar 15 18:22:47 telaviv1.shlomifish.org network[31749]: Bringing up interface eth0: Sorry, there is already an instance of ifplugd for eth0 running. Mar 15 18:22:47 telaviv1.shlomifish.org network[31749]: [FAILED] Mar 15 18:22:47 telaviv1.shlomifish.org network[31749]: Bringing up interface vboxnet0: Sorry, there is already an instance of ifplugd for vboxnet0 running. Mar 15 18:22:47 telaviv1.shlomifish.org network[31749]: [FAILED] Mar 15 18:22:47 telaviv1.shlomifish.org network[31749]: RTNETLINK answers: File exists Mar 15 18:22:47 telaviv1.shlomifish.org network[31749]: RTNETLINK answers: File exists Mar 15 18:22:47 telaviv1.shlomifish.org network[31749]: RTNETLINK answers: File exists Mar 15 18:22:47 telaviv1.shlomifish.org network[31749]: RTNETLINK answers: File exists </journal> > I don't know that it will impact the "no effect" issue, but check your > /etc/sysconfig/network-scripts/ifcfg-* files and make sure there no backup > files for any of the interfaces (*~ or *.bak or *.old, etc) and that the > files for any interfaces you aren't using say ONBOOT=no inside of them. > I've seen both of those issues cause network.service failures, especially on > systemd systems like RHEL7 and newer versions of Mageia. I see : root@telaviv1:~$ ls -l /etc/sysconfig/network-scripts/ifcfg-* -rw-r--r-- 1 root root 45 Jul 12 2015 /etc/sysconfig/network-scripts/ifcfg-enp0s29u1u5 -rw-r--r-- 1 root root 42 May 27 2015 /etc/sysconfig/network-scripts/ifcfg-enp3s0u2 -rwxr-xr-x 1 root root 287 Jan 10 2017 /etc/sysconfig/network-scripts/ifcfg-eth0* -rwxr-xr-x 1 root root 254 Dec 7 2015 /etc/sysconfig/network-scripts/ifcfg-lo* -rw-r--r-- 1 root root 42 Oct 30 2015 /etc/sysconfig/network-scripts/ifcfg-vboxnet0 I copied over an .rpmnew file and the service still reports failure on starting. The two enp* interfaces do not appear in ifconfig. It still happens with latest mga. You seem to have a reference to a non-existing network card: Mar 15 18:22:47 telaviv1.shlomifish.org network[31749]: Bringing up interface enp0s29u1u5: ERROR : [/etc/sysconfig/network-scripts/ifup-eth] Device enp0s29u1u5 does not seem to be present, delaying initialization. (In reply to Shlomi Fish from comment #10) > I see : > > root@telaviv1:~$ ls -l /etc/sysconfig/network-scripts/ifcfg-* > -rw-r--r-- 1 root root 45 Jul 12 2015 > /etc/sysconfig/network-scripts/ifcfg-enp0s29u1u5 > -rw-r--r-- 1 root root 42 May 27 2015 > /etc/sysconfig/network-scripts/ifcfg-enp3s0u2 > -rwxr-xr-x 1 root root 287 Jan 10 2017 > /etc/sysconfig/network-scripts/ifcfg-eth0* > -rwxr-xr-x 1 root root 254 Dec 7 2015 > /etc/sysconfig/network-scripts/ifcfg-lo* > -rw-r--r-- 1 root root 42 Oct 30 2015 > /etc/sysconfig/network-scripts/ifcfg-vboxnet0 I would not have expected to see ifcfg-eth0 and I agree with Thomas that ifcfg-enp0s29u1u5 seems invalid. I suggest the following: cd /etc/sysconfig/network-scripts/ mkdir hold mv ifcfg-eth0 hold/ mv ifcfg-enp0s29u1u5 hold/ systemctl stop network.service systemctl start network.service systemctl status network.service If it looks good, reboot, and ls -l /etc/sysconfig/network-scripts/ifcfg-* systemctl status network.service and if everything look normal rm -r /etc/sysconfig/network-scripts/hold/ CC:
(none) =>
bittwister2 (In reply to Bit Twister from comment #13) > (In reply to Shlomi Fish from comment #10) > > > I see : > > > > root@telaviv1:~$ ls -l /etc/sysconfig/network-scripts/ifcfg-* > > -rw-r--r-- 1 root root 45 Jul 12 2015 > > /etc/sysconfig/network-scripts/ifcfg-enp0s29u1u5 > > -rw-r--r-- 1 root root 42 May 27 2015 > > /etc/sysconfig/network-scripts/ifcfg-enp3s0u2 > > -rwxr-xr-x 1 root root 287 Jan 10 2017 > > /etc/sysconfig/network-scripts/ifcfg-eth0* > > -rwxr-xr-x 1 root root 254 Dec 7 2015 > > /etc/sysconfig/network-scripts/ifcfg-lo* > > -rw-r--r-- 1 root root 42 Oct 30 2015 > > /etc/sysconfig/network-scripts/ifcfg-vboxnet0 > > > I would not have expected to see ifcfg-eth0 and I agree with Thomas that > ifcfg-enp0s29u1u5 seems invalid. > > > I suggest the following: > cd /etc/sysconfig/network-scripts/ > mkdir hold > mv ifcfg-eth0 hold/ > mv ifcfg-enp0s29u1u5 hold/ > > systemctl stop network.service > systemctl start network.service > systemctl status network.service > > If it looks good, reboot, and > ls -l /etc/sysconfig/network-scripts/ifcfg-* > systemctl status network.service > and if everything look normal > > rm -r /etc/sysconfig/network-scripts/hold/ I tried doing all that and more and renamed other strings first to enp... then to eno1 and rebooted several times and the original problem is still present. (In reply to Shlomi Fish from comment #14) > I tried doing all that and more and renamed other strings first to enp... > then to eno1 I suggest that you do not rename any ifcfg-* files to ifcfg-something else because the interface up/down scripts tries to bring up/down ifcfg-* > and rebooted several times and the original problem is still present. I would like to see the results from the following: cd /etc/sysconfig/network-scripts/ /bin/ls -l cd journalctl --no-hostname | grep 'network\[' | grep ERROR Created attachment 10848 [details]
The commands requested by bittwister
If you were to read your attachment details you might notice it is
not easy to read. That is why I asked you to use /bin/ls -l :-(
When you rebooted, I expected to see ifcfg-enp3s0u2 show back up.
Your journal shows both eno1 and vboxnet0 failures.
I would like you to
cd /etc/sysconfig/network-scripts/
mv ifcfg-vboxnet0 hold/
cat ifcfg-eno1
mv ifcfg-eno1 hold/
reboot
cd /etc/sysconfig/network-scripts/
/bin/ls ifcfg-*
cd
journalctl -b --no-hostname | grep 'network\['
journalctl -b --no-hostname | grep 'from eth'
root@telaviv1:~ # cd /etc/sysconfig/network-scripts/ root@telaviv1:/etc/sysconfig/network-scripts # mv ifcf ifcfg-eno1 ifcfg-lo ifcfg-vboxnet0 root@telaviv1:/etc/sysconfig/network-scripts # mv ifcfg-vboxnet0 hold root@telaviv1:/etc/sysconfig/network-scripts # cat ifcfg-eno1 DEVICE=eno1 BOOTPROTO=dhcp NETMASK=255.255.0.0 ONBOOT=yes METRIC=10 MII_NOT_SUPPORTED=no USERCTL=yes DNS1=127.0.0.1 RESOLV_MODS=yes LINK_DETECTION_DELAY=6 IPV6INIT=no IPV6TO4INIT=no ACCOUNTING=no NM_CONTROLLED=yes DHCP_CLIENT=dhclient NEEDHOSTNAME=no PEERDNS=no PEERYP=yes PEERNTPD=no root@telaviv1:/etc/sysconfig/network-scripts # mv ifcf ifcfg-eno1 ifcfg-lo root@telaviv1:/etc/sysconfig/network-scripts # mv ifcfg-eno1 h hold/ hostname.d/ root@telaviv1:/etc/sysconfig/network-scripts # mv ifcfg-eno1 hold mv: overwrite 'hold/ifcfg-eno1'? y After a reboot: root@telaviv1:~ # cd /etc/sysconfig/network-scripts/ root@telaviv1:/etc/sysconfig/network-scripts # /bin/ls ifcfg-* ifcfg-lo root@telaviv1:/etc/sysconfig/network-scripts # cd root@telaviv1:~ # journalctl -b --no-hostname | grep 'network\[' Mar 09 12:54:44 network[2002]: Bringing up loopback interface: [ OK ] root@telaviv1:~ # journalctl -b --no-hostname | grep 'from eth' Mar 09 12:54:23 kernel: e1000e 0000:00:19.0 eno1: renamed from eth0 root@telaviv1:~ # note that i needed to do "sudo dhclient" to get the ipv4 connection up. (In reply to Shlomi Fish from comment #20) > note that i needed to do "sudo dhclient" to get the ipv4 connection up. I often have to do this when I switch off/on my wifi. Looks like the dhcp client gets the offer, puts the ip and the netmask, but the default route is missing. CC:
(none) =>
lists.jjorge (In reply to Shlomi Fish from comment #19) > After a reboot: > > root@telaviv1:~ # cd /etc/sysconfig/network-scripts/ > root@telaviv1:/etc/sysconfig/network-scripts # /bin/ls ifcfg-* > ifcfg-lo > root@telaviv1:/etc/sysconfig/network-scripts # cd > root@telaviv1:~ # journalctl -b --no-hostname | grep 'network\[' > Mar 09 12:54:44 network[2002]: Bringing up loopback interface: [ OK ] > root@telaviv1:~ # journalctl -b --no-hostname | grep 'from eth' > Mar 09 12:54:23 kernel: e1000e 0000:00:19.0 eno1: renamed from eth0 > root@telaviv1:~ # All right. eno1 is the first nic interface card found. After reboot I would have expected it to be found and a ifcfg-enXXX file created. Now, do the following: cd /etc/sysconfig/network-scripts/ cp hold/ifcfg-eno1 . Run the editor of your choice on ifcfg-eno1 and change NM_CONTROLLED=yes to NM_CONTROLLED=no As I misunderstand it, if yes, device is controlled by NetworkManager. if no, controlled by network. You might consider changing LINK_DETECTION_DELAY=6 to 8 or 10. That is the delay network script waits before trying to bring up the device. There is a problem on your setup that your ifcfg-enXXX file was not created upon boot. Possibly because there is another one on the system. As root run updatedb locate eno1 | grep -v hold any other file except /etc/sysconfig/network-scripts/ifcfg-eno1 needs to be examined and maybe removed. After the above ifcfg-eno1 edit/changes, systemctl stop network systemctl start network route -n should show the device. Example only. # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.11.1 0.0.0.0 UG 0 0 0 enp3s0 192.168.11.0 0.0.0.0 255.255.255.0 U 0 0 0 enp3s0 after next reboot, I would expect eno1 to come up. Looking at journal line kernel: e1000e 0000:00:19.0 eno1: I would have expected to see eno1s19: which would make me wonder if the 19 is causing the problem. Examples from two of my systems kernel: r8169 0000:03:00.0 enp3s0: kernel: r8169 0000:02:00.0 enp2s0: (In reply to Bit Twister from comment #22) > (In reply to Shlomi Fish from comment #19) > > After a reboot: > > > > root@telaviv1:~ # cd /etc/sysconfig/network-scripts/ > > root@telaviv1:/etc/sysconfig/network-scripts # /bin/ls ifcfg-* > > ifcfg-lo > > root@telaviv1:/etc/sysconfig/network-scripts # cd > > root@telaviv1:~ # journalctl -b --no-hostname | grep 'network\[' > > Mar 09 12:54:44 network[2002]: Bringing up loopback interface: [ OK ] > > root@telaviv1:~ # journalctl -b --no-hostname | grep 'from eth' > > Mar 09 12:54:23 kernel: e1000e 0000:00:19.0 eno1: renamed from eth0 > > root@telaviv1:~ # > > All right. eno1 is the first nic interface card found. After reboot I would > have expected it to be found and a ifcfg-enXXX file created. > > Now, do the following: > cd /etc/sysconfig/network-scripts/ > cp hold/ifcfg-eno1 . > > Run the editor of your choice on ifcfg-eno1 and > change NM_CONTROLLED=yes > to NM_CONTROLLED=no > > As I misunderstand it, if yes, device is controlled by NetworkManager. > if no, controlled by network. > > You might consider changing LINK_DETECTION_DELAY=6 to 8 or 10. > That is the delay network script waits before trying to bring up the device. > > There is a problem on your setup that your ifcfg-enXXX file was not created > upon boot. > Possibly because there is another one on the system. As root run > updatedb > locate eno1 | grep -v hold > any other file except /etc/sysconfig/network-scripts/ifcfg-eno1 needs > to be examined and maybe removed. > > After the above ifcfg-eno1 edit/changes, > systemctl stop network > systemctl start network > route -n > should show the device. Example only. > > # route -n > Kernel IP routing table > Destination Gateway Genmask Flags Metric Ref Use Iface > 0.0.0.0 192.168.11.1 0.0.0.0 UG 0 0 0 enp3s0 > 192.168.11.0 0.0.0.0 255.255.255.0 U 0 0 0 enp3s0 > > after next reboot, I would expect eno1 to come up. > > Looking at journal line > kernel: e1000e 0000:00:19.0 eno1: > I would have expected to see eno1s19: which would make me wonder if the 19 > is > causing the problem. Examples from two of my systems > kernel: r8169 0000:03:00.0 enp3s0: > kernel: r8169 0000:02:00.0 enp2s0: thanks! It works fine now after all that. Status:
NEW =>
RESOLVED |
Description of problem: As root, "service network {start stop restart}" have no effect. How reproducible: Always. Steps to Reproduce: 1. "service network stop" as root 2. 3.