Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 4 product line. The current stable release is 4.9. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 457164

Summary: traceroute prevents netdump start at boot
Product: Red Hat Enterprise Linux 4 Reporter: Kilian Cavalotti <kilian>
Component: tracerouteAssignee: Jiri Skala <jskala>
Status: CLOSED WONTFIX QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: 4.6CC: aglotov, dmitry
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-02-23 13:46:52 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
netdump start logs none

Description Kilian Cavalotti 2008-07-30 00:14:09 UTC
Description of problem:

When configured to start at boot, netdump (client) fails to start because of 
traceroute. It seems like netdump starts a bit early, before the network is 
actually up, and fails. Which would be ok if its exit code was not 0. But it 
does return 0, so the netdump start script assumes it's ok, parses the output 
line, and get the wrong IP address (actually the client address) as the 
netdump server address. Which makes it definitely fails.

Attached are two verbose logs of the start() section of /etc/init.d/netdump, 
one executed at boot time (it fails), and one executed once the machine is up 
and running. 10.0.0.2 is the netdump server, 10.0.1.29 is the client. 

The failing part is the following:

++ host_ip=10.0.0.2
traceroute -i $DEV -n -m 1 $host_ip 2> /dev/null
+++ traceroute -i eth0 -n -m 1 10.0.0.2
++ trc_output=' 1  10.0.1.29  3003.783 ms !H  3006.673 ms !H 10.0.0.2  10.227 
ms'

Here, the output of traceroute is a failure.

++ '[' 0 -eq 0 ']'

But the exit code is 0.

echo $trc_output | grep '^1 ' | awk '{print $2}'
+++ echo 1 10.0.1.29 3003.783 ms '!H' 3006.673 ms '!H' 10.0.0.2 10.227 ms
+++ grep '^1 '
+++ awk '{print $2}'
++ trc_output=10.0.1.29

Then, after parsing trceroute's output, the client IP address (10.0.1.29) 
replaced the server one (10.0.0.2)


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

netdump-0.7.16-14.x86_64
traceroute-1.4a12-24.EL4.1.x86_64


How reproducible:

Always


Expected result:

traceroute shouldn't return 0 when it fails. Tracerouting a non existent IP 
address, it always returns 0:

# ping -n -c 1 10.0.99.99
PING 10.0.99.99 (10.0.99.99) 56(84) bytes of data.
From 10.0.1.29 icmp_seq=0 Destination Host Unreachable

--- 10.0.99.99 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
, pipe 2
# echo $?
1

# traceroute -n -m 1 10.0.99.99
traceroute to 10.0.99.99 (10.0.99.99), 1 hops max, 46 byte packets
 1  10.0.1.29  3010.827 ms !H  3016.494 ms !H  3006.206 ms !H
# echo $?
0

Comment 1 Kilian Cavalotti 2008-07-30 00:14:09 UTC
Created attachment 312950 [details]
netdump start logs

Comment 2 Dmitry Butskoy 2008-09-17 15:27:21 UTC
> Here, the output of traceroute is a failure.

Please, note that "!H" etc. is *not failure* output, it is just *information* output, as well as another data printed about the network path. All this info is printed into stdout (not stderr), which also shows that it is not an error.

The example of error output could be:
"socket: Permission denied"
in the stderr, etc.

It is not a task for traceroute "either to reach the destination host or to abort". The traceroute's task is just show the network path. For "reach or abort" scheme some another application should be used (perhaps nc(1), or maybe ping(1) ).

Comment 3 RHEL Program Management 2008-10-31 16:37:40 UTC
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".

Comment 4 Jiri Skala 2010-02-23 13:46:52 UTC
As mentioned in comment #2 this is easy replaceable so I'm going to close it.