Bug 144882

Summary: Arping utility hangs if SIGALRM blocked
Product: Red Hat Enterprise Linux 3 Reporter: Atul Verma <averma00>
Component: iputilsAssignee: Radek Vokál <rvokal>
Status: CLOSED WORKSFORME QA Contact: Mike McLean <mikem>
Severity: low Docs Contact:
Priority: medium    
Version: 3.0   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1085971 (view as bug list) Environment:
Last Closed: 2005-05-12 08:26:32 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
C file to reproduce the bug none

Description Atul Verma 2005-01-12 14:17:47 UTC 
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Texas 
Instruments; .NET CLR 1.1.4322)

Description of problem:
If "arping" utility is forked (using system() library function) from 
a parent process in which SIGALRM signal is blocked then the system() 
function call never returns.

The problem is that arping utility installs a SIGALRM handler but 
does not bother to unblock it - so its logic does not work if it 
inherited blocked SIGALRM.

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

How reproducible:
Always

Steps to Reproduce:
1.Block SIGALRM signal
2.Call srping utility ising system() library function
3.Observe that system() function never returns
    

Actual Results:  The process hangs forever

Expected Results:  The process should have exited

Additional info:
Comment 1 Atul Verma 2005-01-12 14:21:58 UTC 
Created attachment 109666 [details]
C file to reproduce the bug
Comment 2 Radek Vokál 2005-01-17 11:47:18 UTC 
This comes from your test C code. I see what you mean with SIGALRM
locked but it works on my machine.

# ./mytest1
Executing command [arping -c 1 -I eth0 192.168.1.1]
ARPING 192.168.1.1 from 192.168.1.13 eth0
Unicast reply from 192.168.1.1 [00:10:4B:6B:18:87]  5.317ms
Sent 1 probes (1 broadcast(s))
Received 1 response(s)
System call returned with status 0

# rpm -q iputils
iputils-20020927-19 (includes updated ifenslave, might fix the issue)
Comment 3 Radek Vokál 2005-05-12 08:26:32 UTC 
retested, problem not found