Bug 1128830
| Summary: | addCopySpecs doesn't copy symlinks | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Sandro Bonazzola <sbonazzo> |
| Component: | sos | Assignee: | Shane Bradley <sbradley> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | BaseOS QE - Apps <qe-baseos-apps> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.5 | CC: | agk, bmr, gavin, sbonazzo, sbradley |
| Target Milestone: | rc | ||
| Target Release: | 6.6 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-10-30 18:19:29 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1128738 | ||
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'). 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. This should be addressed in 6.7. |
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.