Bug 819137 - lscgroup drops first character of path unless prefixed with slash
lscgroup drops first character of path unless prefixed with slash
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libcgroup (Show other bugs)
All Linux
medium Severity medium
: rc
: ---
Assigned To: Peter Schiffer
Mike Gahagan
Depends On:
Blocks: 782183 840683 787802 819568 819574
  Show dependency treegraph
Reported: 2012-05-04 22:38 EDT by Travis Gummels
Modified: 2013-02-21 05:47 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: lscgroup drops first character of path unless prefixed with slash Consequence: possibility to generate invalid path Fix: do not drop first character of path Result: lscgroup doesn't drop first character of path if path is not prefixed with slash
Story Points: ---
Clone Of:
: 819568 819574 (view as bug list)
Last Closed: 2013-02-21 05:47:19 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
patch to underlying problem (1.26 KB, patch)
2012-05-14 13:44 EDT, Ben Woodard
no flags Details | Diff

  None (edit)
Description Travis Gummels 2012-05-04 22:38:31 EDT
Description of problem:

lscgroup ltrims path unless prefixed with slash.

$ lscgroup freezer:/libvirt

$ lscgroup freezer:libvirt

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


How reproducible:

Steps to Reproduce:
See above.
Actual results:
first character of path dropped

Expected results:
path kept intact

Additional info:
LLNL requests this BZ made public.
Comment 2 Ivana Varekova 2012-05-10 03:14:28 EDT
Fixed in upstream: https://sourceforge.net/mailarchive/message.php?msg_id=29243208
Comment 3 Ben Woodard 2012-05-14 13:44:26 EDT
Created attachment 584420 [details]
patch to underlying problem

Ivana, there is a deeper underlying problem and a harmless bug.

If you look at this attached patch you will see that in many cases there is a double "/" in the path it is constructing in the api.c so it ends up with a "//" in the middle of the path that it is going to look in. This appears to be a bug that was worked around with the +1 over in lsgroup.c So removing the addition of the 2nd "/" makes everything work correctly and the workaround is not needed.

Also while debugging this, I discovered another harmless cut/paste bug.
Comment 4 Ivana Varekova 2012-06-30 04:34:29 EDT
now upstream patch changes api function not to add "/" character when it is not needed and lscgroup does not remove "/" itself
Comment 8 Mike Gahagan 2012-12-19 15:08:55 EST
Confirmed fix for this bug is in libcgroup-0.37-6

[root@dhcp137-133 tmp]# lscgroup memory:load-tasks
[root@dhcp137-133 tmp]# lscgroup memory:/load-tasks
[root@dhcp137-133 tmp]# rpm -q libcgroup

rpm -Fvh                          
[root@dhcp137-133 tests]# rpm -q libcgroup                                                            
[root@dhcp137-133 tmp]# lscgroup memory:load-tasks
[root@dhcp137-133 tmp]# lscgroup memory:/load-tasks
Comment 10 errata-xmlrpc 2013-02-21 05:47:19 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.