Bug 245011

Summary: tc hardcodes paths for shared object which breaks on 64bit systems.
Product: Red Hat Enterprise Linux 4 Reporter: Oliver Cook <oliver.cook>
Component: iprouteAssignee: Marcela Mašláňová <mmaslano>
Status: CLOSED ERRATA QA Contact: Brock Organ <borgan>
Severity: low Docs Contact:
Priority: low    
Version: 4.4   
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: 2008-01-18 12:41:54 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
one possible fix none

Description Oliver Cook 2007-06-20 15:01:37 UTC
Description of problem:

In trying to run tc with netem to introduce latency in the lab on a 64bit system
I discovered the following bug in get_qdisc_kind  in tc.c:

        snprintf(buf, sizeof(buf), "/usr/lib/tc/q_%s.so", str);

The path to the tc qdisc shared objects is hard-coded. On a 64bit system the
correct path is /usr/lib64/tc/.

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


How reproducible:

100% reproducible

Steps to Reproduce:
1. tc qdisc add dev eth0 root netem delay 100ms
2. output upon failure is: "Unknown qdisc "netem", hence option "delay" is
unparsable"

Or.

1. strace tc qdisc add dev eth0 root netem delay 100ms 2>&1|grep netem
2. output upon failure is: execve("/sbin/tc", ["tc", "qdisc", "add", "dev",
"eth0", "root", "netem",
  "delay", "100ms"], [/* 20 vars */]) = 0
  open("/usr/lib/tc/q_netem.so", O_RDONLY) = -1 ENOENT (No such file or
  directory)

Additional info:

A workaround is to symlink /usr/lib/tc/ to /usr/lib64/tc.

A patch that tries first /usr/lib/tc then /usr/lib64/tc is available at
http://www.olliecook.net/patches/tc.c.64bit.patch for your consideration,
although probably isn't the 'right way' to fix this.

I raised this with the linux-net mailing list. The maintainer replied that:

"That is a distro choice to change the path on 64bit, not all do. So please
report it as a bug to the distro."

Comment 1 Oliver Cook 2007-06-20 15:01:37 UTC
Created attachment 157472 [details]
one possible fix

Comment 2 RHEL Program Management 2007-11-29 04:18:46 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Comment 5 Marcela Mašláňová 2008-01-18 12:41:54 UTC
I'm sorry this bug was already fixed in version iproute-2.6.9-3.EL4.4 and
higher. I've tested it on x86_64 RHEL4 and it's ok.