Hide Forgot
Description of problem: Boot the system with the following configuration: $ cat /etc/systemd/network/host0.network [Match] Name=host0 [Network] IPForward=no Address=fd3b:d910:cd43::3/127 $ $ cat /etc/systemd/network/wired.network [Match] Name=eth2 [Network] IPForward=no $ $ cat /etc/systemd/system/systemd-networkd.service.d/local.conf [Service] ExecStartPre=-/sbin/ip link set eth2 down ExecStartPre=-/sbin/ip addr flush dev eth2 Restart=on-failure $ $ cat /etc/cups/cupsd.conf MaxLogSize 0 LogLevel warn Listen localhost:631 Listen /var/run/cups/cups.sock Listen [fd3b:d910:cd43::3]:631 Browsing Off DefaultShared no WebInterface Yes DefaultEncryption Never HostNameLookups off <Location /> Order allow,deny Allow from all </Location> <Policy default> <Limit All> Allow from All </Limit> </Policy> $ $ cat /etc/systemd/system/cups.service.d/local.conf [Service] ExecStartPre=/bin/sleep 2 LimitCORE=1073741824 $ Change the network configuration to match this: $ cat /etc/systemd/network/wired.network [Match] Name=eth2 [Network] IPForward=no DHCP=ipv4 [DHCP] UseHostname=true SendHostname=true $ Perform a restart of network: $ systemctl restart systemd-networkd.service $ Load CUPS webinterface from a client: $ wget -q http://[fd3b:d910:cd43::3]:631/ $ Receive the segmentation fault slightly (2-3 seconds later) afterwards: Apr 06 23:35:19 tux systemd[1]: cups.service: main process exited, code=dumped, status=11/SEGV Apr 06 23:35:19 tux systemd[1]: Unit cups.service entered failed state. Apr 06 23:35:19 tux systemd[1]: cups.service failed. Version-Release number of selected component (if applicable): cups-1.6.3-22.el7.x86_64 systemd-networkd-219-19.el7_2.7.x86_64 How reproducible: Everytime, see above. Actual results: CUPS segfaults slightly after restart of systemd-networkd. Expected results: No segmentation fault of CUPS. Additional info: Note that the IPv6 address and the hostname has been obfuscated here and in the backtrace by using a random IPv6 address range from the ULA range.
Created attachment 1144450 [details] Rest of terminal output of "strace -ff -p 1853 -s 4096"
Created attachment 1144453 [details] Output of "gdb /usr/sbin/cupsd /core.1853"
Cross-filed case 01614836 on the Red Hat customer portal.
Hi Robert, I am sorry, but I can not reproduce this problem. My environment is following: Fedora 23 - host machine RHEL 7.2 - guest machine in KVM I created isolated virtual network "isol" (without DHCP, internal and host routing only) in KVM (this created "virbr1" connection on Fedora, I assigned static IPv6 address fd3b:d910:cd43::1/112 to it). I used this network as network source for virtual network interface for guest machine of RHEL 7.2, which created interface "ens9". I assigned static IPv6 address fd3b:d910:cd43::3/112 to this interface. After that, I followed your instructions and configure files accordingly: $ cat /etc/systemd/network/ens9.network [Match] Name=ens9 [Network] IPForward=no Address=fd3b:d910:cd43::3/127 $ $ cat /etc/systemd/network/wired.network [Match] Name=eth0 [Network] IPForward=no $ $ cat /etc/systemd/system/systemd-networkd.service.d/local.conf [Service] ExecStartPre=-/sbin/ip link set eth0 down ExecStartPre=-/sbin/ip addr flush dev eth0 Restart=on-failure $ $ cat /etc/cups/cupsd.conf MaxLogSize 0 LogLevel warn Listen localhost:631 Listen /var/run/cups/cups.sock Listen [fd3b:d910:cd43::3]:631 Browsing Off DefaultShared no WebInterface Yes DefaultEncryption Never HostNameLookups off <Location /> Order allow,deny Allow from all </Location> <Policy default> <Limit All> Allow from All </Limit> </Policy> $ $ cat /etc/systemd/system/cups.service.d/local.conf [Service] ExecStartPre=/bin/sleep 2 LimitCORE=1073741824 $ Change the network configuration to match this: $ cat /etc/systemd/network/wired.network [Match] Name=eth0 [Network] IPForward=no DHCP=ipv4 [DHCP] UseHostname=true SendHostname=true $ Then I restart of systemd-networkd. But after that, when I enter the command $ wget -q http://[fd3b:d910:cd43::3]:631/ from Fedora, it correctly downloads file index.html and cupsd is still running. No segfault happens. Firewall on RHEL is set up to allow incoming communication on port 631. NetworkManager on RHEL is stopped and disabled. Do you see any errors in my configuration? If you don't, can you please provide me more detailed configuration for reproducing this bug?
Hello Zdenek, the steps seem to be correct. Unfortunately, I deleted my testing VM already, thus I will have to setup it again. Does the backtrace of the core dump help somehow? This also should outline some details.
I looked into backtrace and I think it might be problem in glibc. What version of glibc did you have at that time?
glibc-2.17-106.el7_2.4 (latest stable 7.2 release at that time)
Robert, can you setup your testing VM again, please? Because I will pass this bug into glibc component, so Florian will probably need it.
(In reply to Robert Scheck from comment #8) > glibc-2.17-106.el7_2.4 (latest stable 7.2 release at that time) This issue has been addressed in glibc-2.17-106.el7_2.6. *** This bug has been marked as a duplicate of bug 1323839 ***
Okay, given Florian marked it as duplicate of a fixed bug, I assume that a testing VM is no longer needed?
(In reply to Robert Scheck from comment #11) > Okay, given Florian marked it as duplicate of a fixed bug, I assume that a > testing VM is no longer needed? No, we don't need the VM—unless the issue still occurs with glibc-2.17-106.el7_2.6. But the backtrace and other circumstances really match bug 1323839 and the corresponding upstream bug, so I expect it is indeed fixed.