Bug 1128830 - addCopySpecs doesn't copy symlinks
Summary: addCopySpecs doesn't copy symlinks
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sos
Version: 6.5
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 6.6
Assignee: Shane Bradley
QA Contact: BaseOS QE - Apps
URL:
Whiteboard:
Depends On:
Blocks: 1128738
TreeView+ depends on / blocked
 
Reported: 2014-08-11 15:28 UTC by Sandro Bonazzola
Modified: 2015-10-30 18:19 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-10-30 18:19:29 UTC


Attachments (Terms of Use)

Description Sandro Bonazzola 2014-08-11 15:28:02 UTC
in rhevm-log-collector the ovirt plugin uses 

 self.addCopySpecs([
            "/etc/ovirt-engine",
            "/etc/rhevm",
            ...
 ])

where /etc/rhevm is a symlink to /etc/ovirt-engine.

the resulting report is missing /etc/rhevm.
As workaround I can use 

 self.addCopySpecs([
            "/etc/ovirt-engine",
            "/etc/rhevm/*",
            ...
 ])

but this will duplicate the files instead of just creating the symlink.

Comment 1 Bryn M. Reeves 2014-08-21 17:48:36 UTC
This is expected behaviour for sos-2.x. Since we allow directories to be recursively added to the report via addCopySpec() we cannot copy the targets of symbolic links that point to directories.

This is because in a file system like /sys if you enable symlink traversal during a recursive copy you wind up in an infinite loop (the symlinked directory structure is more like a directed cyclic graph than a tree).

E.g. starting from the dm-0 entry in block/ we quickly encounter a directory cycle due to the subsystem links that point back from the devices/virtual/block tree into the class/block/ tree and back into block/:

/sys/block/dm-0 -> ../devices/virtual/block/dm-0

../devices/virtual/block/dm-0/subsystem -> ../../../../class/block

../../../../class/block/dm-0 -> ../../devices/virtual/block/dm-0

Upstream we've done a lot of work over the last six months to clean up the file copying code and improve the handling of virtual file systems and symlinks. We were hoping to be able to backport this via bug 1090483 however the code is still relatively new (it's only been in a single alpha release upstream) and I'm very wary of introducing a regression in 6.6 due to these changes.

The normal trick for plugin writers in 2.x is to make it explicit that a directory is being collected by including a trailing '/', e.g. see the networking plugin that has:

 71         self.addCopySpec("/proc/net/")
 72         self.addForbiddenPath("/proc/net//rpc/*/channel")
 73         self.addForbiddenPath("/proc/net//rpc/*/flush")

(the double-slashing in the forbidden paths list is to ensure we get a string match with the additional slash).

You mentioned this wasn't working for you in your testing but I just tried this out on an el6 machine and it's behaving as expected.

Do you have a test machine I can take a look at where you're seeing this?

Also, I'm guessing that on some installations '/etc/rhev' is an actual directory rather than a symlink? (otherwise I'm not really sure why you care about collecting both '/etc/ovirt-engine' and what's presumably always '/etc/rhev -> /etc/ovirt-engine').

Comment 2 Sandro Bonazzola 2014-08-26 06:59:11 UTC
As far as I know /etc/rhev should be a symlink on cleanly installed hosts starting with rhevm 3.3. Not sure if it's a directory when upgrading from earlier versions. GSS asked to include the directory/symlink tree as well.

Tried to reproduce the issue about missing inclusion with trailing / instead of /* without success. It seems to work.

Comment 4 Bryn M. Reeves 2015-10-30 18:19:29 UTC
This should be addressed in 6.7.


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