Bug 1085971

I wonder what "certain circumstances" might be? Something doesn't feel right about this bug. Yes, it does block the process, but the example looks pretty artificial. It also feels something like "hey, I passed an invalid pointer to free() and it segfaulted" kind of problem.

Care to elaborate?

I found this problem on a lab (used for a Networking Lab course) with PCs running fedora, where ifup was hanging on about 1/3 of them because of dhclient, so the problem definitely occurs in practice and is not some "I passed an invalid pointer to free() and it segfaulted" kind of problem.

After closer inspection, I found out that this was due to /sbin/dhclient-script invoking arping for duplicate address detection and arping not exiting (as it is supposed to do after a couple of seconds).  Running arping on the command line yielded similar results (it hangs on about 1/3 of the PCs in the lab).

Using strace I found out that arping was calling alarm(1) before calling recvfrom(), in order to interrupt the latter after 1s in case nothing is received (the normal case), but it had no effect -- recvfrom() was blocking ad eternum.

I searched bugzilla for a similar report and found out the bug I ended up cloning.  Admittedly, the example is quite artificial, but it does illustrate, in a 100% reproducible way, a problem that occurs in practice, as explained above.

I am still unsure of what is causing the system to block SIGALRM (especially since it does not affect all PCs, only about 1/3, all of them running a similar installation of Fedora 20), so further investigation will be required.  Anyway, I hacked a temporary fix by commenting out the duplicate address detection part in /sbin/dhclient-script, but the real fix needs to be done in arping.c.

By the way, as you can see the patch is both trivial and harmless.  It also does solve a problem.  I could have contacted directly the author of arping or the maintainer of iputils, but figured that posting the bug report here along with the patch would be the fastest way to get it fixed in the Linux distribution I am using, and it would end up getting to them anyway.

Thank you for the explanation. Would you mind changing your patch and putting a comment above the unblocking part of it explaining why it is unblocking stuff first? I will apply the patch, but I think it needs to be explained, since it's pretty surprising if you don't know the background. I'll also mention the bugzilla in the header.

Thank you very much for your interest, Jan.  Here is the patch with the explanation:

--- iputils-s20121221-orig/arping.c     2014-04-10 15:41:29.158243387 +0100
+++ iputils-s20121221-new/arping.c      2014-04-10 16:02:06.000000000 +0100
@@ -1215,16 +1215,22 @@
                socklen_t alen = sizeof(from);
                int cc;

+               sigemptyset(&sset);
+               sigaddset(&sset, SIGALRM);
+               sigaddset(&sset, SIGINT);
+               /* Unblock SIGALRM so that the previously called alarm()
+                * can prevent recvfrom from blocking forever in case the
+                * inherited procmask is blocking SIGALRM and no packet
+                * is received. */
+               sigprocmask(SIG_UNBLOCK, &sset, &osset);
+
                if ((cc = recvfrom(s, packet, sizeof(packet), 0,
                                   (struct sockaddr *)&from, &alen)) < 0) {
                        perror("arping: recvfrom");
                        continue;
                }

-               sigemptyset(&sset);
-               sigaddset(&sset, SIGALRM);
-               sigaddset(&sset, SIGINT);
-               sigprocmask(SIG_BLOCK, &sset, &osset);
+               sigprocmask(SIG_BLOCK, &sset, NULL);
                recv_pack(packet, cc, (struct sockaddr_ll *)&from);
                sigprocmask(SIG_SETMASK, &osset, NULL);
        }

Pushed:
http://pkgs.fedoraproject.org/cgit/iputils.git/commit/?h=f20&id=7d292a6b5a3d03016ce7395eaeb45ea4cc3b0a83

iputils-20121221-6.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/iputils-20121221-6.fc20

Package iputils-20121221-6.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing iputils-20121221-6.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-5072/iputils-20121221-6.fc20
then log in and leave karma (feedback).

iputils-20121221-6.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.