| Summary: | some pipe pmda issues | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Frank Ch. Eigler <fche> |
| Component: | pcp | Assignee: | Nathan Scott <nathans> |
| Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 22 | CC: | brolley, fche, lberk, mbenitez, mgoodwin, nathans, pcp, scox |
| 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: | 2016-07-19 18:38:37 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: | |
|
Description
Frank Ch. Eigler
2016-01-04 19:54:23 UTC
# pmval -i rw_syscalls -x $$ pipe.firehose results in no output, but a spinning perf-script process left around in the background (In reply to Frank Ch. Eigler from comment #0) > In pcp-3.10.9-1.fc22.x86_64: > Thanks for trying it out. > - the pipe pmda is in the core pcp rpm instead of a subrpm Thats by design. There are a number of small, core PMDAs with no external dependencies in the core pcp package, and I felt this was useful enough that it should be with those. > - it does not include an empty /etc/pcp/pipe.conf.d directory, without which > the pmda startup fails $ rpm -qf /etc/pcp/pipe.conf.d pcp-3.11.0-1.x86_64 > - it should probably include at least a blank pipe.conf file (owned by > root!) so the pmda will at least start A blank pipe.conf buys nothing (pmdapipe will still not start). I'm not really convinced we should have a default - I couldn't come up with anything that would be OK to run as root without someone explicitly asking for that (perhaps exit(0)? but again, not useful). > (for testing purposes) See qa/878. > - it excludes the pmdapipe man page Its in pcp-doc with everything else. > - the pmdapipe page does not explain what happens security-wise if there is > no [access] clause *nod* > - the pmdapipe page does not explain invocation-parameter quoting rules, > such as for passing metacharacters or embedded spaces *nod* - shell metacharacters and embedded spaces are not permitted in the config by design (its not run via sh(1)) - should make a note. > - the sample.conf should have an [access] block that makes it less likely > that someone installing the sample.conf as pipe.conf will thereby give > random local users access to the running-as-root programs therein, since the Right. These are the sorts of reasons why I didn't install a default config on the users behalf - I think people should always opt-in. > [access]-less default appears to be to GRANT access *nod* > - installing said sample.conf as pipe.conf, restarting pmcd, then running > Is qa/878 passing on this machine? I'll dig deeper into some of these other issues shorty, thanks. > # pmval -i bdev_trace pipe.firehose > results in no output; no errors; no log entries; as per strace no attempt to > run the btrace binary; some pmda -Dall suggests internal error -12391 at > some point; because of bug #1229494, one can't strace -Dall effectively > > # pmval -i bdev_trace -x "5 BADDEVICE" pipe.firehose > results in no output, even though btrace must have signalled a failure on > its stderr; similarly no log/output if the /usr/bin/btrace program is not > installed at all > > # pmval -i bdev_trace -x "5 DEVICE" pipe.firehose > results in output; the [end] flag is set on many of the last lines, so they > don't match up with the single [start]-flagged line at the top; > event-flagging behaviour should be documented in man page > > # pmval -i bdev_trace -x "5 DEVICE JUNK JUNK JUNK" pipe.firehose > quietly ignores JUNK; if this is desirable, it should be documented > > # pmval -i rw_syscalls -x /dev/null pipe.firehose > results in pmval: store value "/dev/null" failed: Bad input to pmstore > which would be OK if it were to signal that "perf script rw-by-file" errors > out on that input, but that's probably not what it means. The above look like access control and config documentation issues at first glance FWLIW. > # pmval -Dall -i bdev_trace -x '50 /dev/md0' pipe.firehose > results in a SEGV; valgrind has multiple complaints Can you post all those details please? Taa. > - cursory code review shows numerous unchecked strdup() calls; consider at > least assert()ing those against OOM IIRC, those are in places where subsequent checks will error out later on, but will double check. Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |