| Summary: | --mappings and --users fails for unprivileged user | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Oliver Henshaw <oliver.henshaw> |
| Component: | smem | Assignee: | Matthew Miller <mattdm> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 16 | CC: | mattdm, mschmidt |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-12-11 01:33:23 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
Thanks. I've passed on the report to the upstream mailing list; we'll see what happens there. This seems to have been fixed upstream and tagged 1.1, but there's no 1.1 release in http://www.selenic.com/smem/download/ smem-1.2-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/smem-1.2-1.fc18 smem-1.2-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/smem-1.2-1.fc17 Package smem-1.2-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing smem-1.2-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-17255/smem-1.2-1.fc18 then log in and leave karma (feedback). smem-1.2-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report. |
Description of problem: smem silently fails when invoked with --mappings or --user as non-root. i.e.: $ smem -m $ smem -u $ but these commands work as expected when called by root. And 'smem', with no arguments, works for any user. The problem seems to be that the user doesn't have permission to e.g. /proc/1/smaps. The naive solution is to 'continue' to the next pid rather than 'raise', as in the showpids() path, i.e.: --- /usr/bin/smem 2011-02-16 22:26:56.000000000 +0000 +++ ./smem 2011-11-28 22:32:24.977732268 +0000 @@ -298,7 +298,7 @@ def maptotals(pids): seen[name] = 1 totals[name] = t except: - raise + continue return totals def showmaps(): @@ -348,7 +348,7 @@ def usertotals(pids): if len(maps) == 0: continue except: - raise + continue user = src.piduser(pid) if user not in totals: t = dict(size=0, rss=0, pss=0, shared_clean=0, but there may be some subtlety I've missed. Version-Release number of selected component (if applicable): smem-1.0-2.fc16.noarch