| Summary: | systemd fiddles with network interfaces when it shouldn't | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | udo <udovdh> |
| Component: | systemd | Assignee: | systemd-maint |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 15 | CC: | harald, johannbg, johannbg, lpoetter, metherid, mschmidt, notting, plautrba |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-01-25 16:22:18 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
This process also destroys my /etc/resolv.conf. It gets the text: # No nameservers found; try putting DNS servers into your # ifcfg files in /etc/sysconfig/network-scripts like so: # # DNS1=xxx.xxx.xxx.xxx # DNS2=xxx.xxx.xxx.xxx # DOMAIN=lab.foo.com bar.foo.com When my ifcfg-eth0 DOES have a DNS1 line. So systemd triggers NM? or whatever and NM does it's evil and wrongful job. Why can'tanybody get NM to work right? It's a wired system, how simple can it get?! You have the network service configured to start in both runlevel 3 and runlevel 5. Apparently, it failed when attempting to start in runlevel 3. systemd tracked that. Since it's configured to start in runlevel 5, when you switch to it, it attempts to start it again. How did I do that? I do not recall a conscious attempt to do so. Where would I look to fix this? I can then fix and retest and maybe we can close the bug. (In reply to comment #3) > How did I do that? Presumably, 'chkconfig network on', or something along those lines. > I do not recall a conscious attempt to do so. > Where would I look to fix this? chkconfig --list network You'd turn it off with 'chkconfig network off'. Network is set to be running in runlevels 2, 3, 4 and 5. As it always has. The fact that an attempt is made to START the network means that the system (systemd, NM or whatever) does not know the current state of the network. This really is a change from pre-F15 behaviour. If the network is on, neither NM nor systemd should touch it except when the runlevels change so much that it should be stopped. What does 'systemctl status network.service' show before you start switching the runlevels? # systemctl status network.service network.service - LSB: Bring up/down networking Loaded: loaded (/etc/rc.d/init.d/network) Active: failed since Tue, 19 Jul 2011 17:58:35 +0200; 24h ago CGroup: name=systemd:/system/network.service And this is when we DO have network. Last time it ran was due to `init3;init 5` so the failure is explained by the fact that the interfaces were already up... Similar issues (trying to start when already up and OK) happen with swap due to encrypted swap issues. So stuff is not flawless to put it mildly. The script returned failure, because one of your configured interfaces failed to come up. Not sure what else we should do here ... lie? Adding 1036188k swap on /dev/mapper/swapb. Priority:0 extents:1 across:1036188k Adding 1036188k swap on /dev/mapper/swapa. Priority:0 extents:1 across:1036188k Adding 1036188k swap on /dev/mapper/swapd. Priority:0 extents:1 across:1036188k Adding 1036188k swap on /dev/mapper/swapc. Priority:0 extents:1 across:1036188k swapon[30320]: swapon: /dev/dm-10: swapon failed: Device or resource busy swapon[30322]: swapon: /dev/dm-11: swapon failed: Device or resource busy swapon[30334]: swapon: /dev/dm-12: swapon failed: Device or resource busy swapon[30343]: swapon: /dev/dm-13: swapon failed: Device or resource busy packagekitd[29471]: segfault at 8 ip 0000000000412916 sp 00007fffe2172a90 error 4 in packagekitd[400000+51000] bluetoothd[31056]: segfault at 7fe0703caf20 ip 00007fe06ddad721 sp 00007fffde9d99a8 error 4 in bluetoothd[7fe06dd6d000+8b000] swapon[2717]: swapon: /dev/dm-10: swapon failed: Device or resource busy swapon[2719]: swapon: /dev/dm-11: swapon failed: Device or resource busy swapon[2733]: swapon: /dev/dm-12: swapon failed: Device or resource busy swapon[2743]: swapon: /dev/dm-13: swapon failed: Device or resource busy swapon[3380]: swapon: /dev/dm-10: swapon failed: Device or resource busy swapon[3391]: swapon: /dev/dm-11: swapon failed: Device or resource busy swapon[3402]: swapon: /dev/dm-12: swapon failed: Device or resource busy swapon[3408]: swapon: /dev/dm-13: swapon failed: Device or resource busy bluetoothd[4154]: segfault at 7f036c6327b0 ip 00007f036a94b721 sp 00007fff5350c178 error 4 in bluetoothd[7f036a90b000+8b000] swapon[5004]: swapon: /dev/dm-10: swapon failed: Device or resource busy swapon[5013]: swapon: /dev/dm-11: swapon failed: Device or resource busy swapon[5024]: swapon: /dev/dm-12: swapon failed: Device or resource busy swapon[5030]: swapon: /dev/dm-13: swapon failed: Device or resource busy swapon[5181]: swapon: /dev/dm-10: swapon failed: Device or resource busy swapon[5183]: swapon: /dev/dm-11: swapon failed: Device or resource busy swapon[5189]: swapon: /dev/dm-12: swapon failed: Device or resource busy swapon[5195]: swapon: /dev/dm-13: swapon failed: Device or resource busy packagekitd[4183]: segfault at 8 ip 0000000000412916 sp 00007fff1d467410 error 4 in packagekitd[400000+51000] usb0: no IPv6 routers present See the swap stuff? Same deal. systemd remembers a state. It doesn't check with reality. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. So checking with reality is not necessary, and thought of as a feature? NetworkManager is a mess when you have a USB with a variable mac address. systemd plus NM is even worse as you can see above. None of this is seen as an issue. None of it is comprehended. None of it is fixed. And put that in a light of the past when a 'service network restart' fixed all that NM messed up, no work was needed when going from runlevel 5 to 3 or even back. We're at F16 now but I'll surely re-test soon. Because did you? Some of the symptoms I see here match bug 708537. |
Description of problem: When changing runlevels or whatever they are called now, is bringing up an interface that already is up really necessary? Version-Release number of selected component (if applicable): systemd-26-8.fc15 How reproducible: be in gui mode switch to a text console log in there be root do:` init 3; init 5` Steps to Reproduce: 1. see above 2. 3. Actual results: see below Expected results: no such mess Additional info: [root@surfplank2 ~]# init 3 bluetoothd[31056]: segfault at 7fe0703caf20 ip 00007fe06ddad721 sp 00007fffde9d99a8 error 4 in bluetoothd[7fe06dd6d000+8b000] Bringing up loopback interface: [ OK ] Bringing up interface eth0: [root@surfplank2 ~]# Active connection state: activating Active connection path: /org/freedesktop/NetworkManager/ActiveConnection/3 state: activated Connection activated [ OK ] Bringing up interface usb0: ERROR : [/etc/sysconfig/network-scripts/ifup-eth] Device usb0 has different MAC address than expected, ignoring. [FAILED] RTNETLINK answers: File exists RTNETLINK answers: File exists RTNETLINK answers: File exists RTNETLINK answers: File exists RTNETLINK answers: File exists RTNETLINK answers: File exists RTNETLINK answers: File exists RTNETLINK answers: File exists RTNETLINK answers: File exists [root@surfplank2 ~]# init 5 Bringing up loopback interface: [ OK ] Bringing up interface eth0: [root@surfplank2 ~]# Active connection state: activating Active connection path: /org/freedesktop/NetworkManager/ActiveConnection/4 state: activated Connection activated [ OK ] Bringing up interface usb0: ERROR : [/etc/sysconfig/network-scripts/ifup-eth] Device usb0 has different MAC address than expected, ignoring. [FAILED] RTNETLINK answers: File exists RTNETLINK answers: File exists RTNETLINK answers: File exists RTNETLINK answers: File exists RTNETLINK answers: File exists RTNETLINK answers: File exists RTNETLINK answers: File exists RTNETLINK answers: File exists RTNETLINK answers: File exists [root@surfplank2 ~]# Yes, we also see NetworkManager ignorance in between. It still doesn't handle an interface with a changing mac adresss as it should. It still thinks it needs to do udev's job. Of course eth0 was already up