Red Hat Bugzilla – Bug 968381
"rlRun -s" design leads to /dev/null removal
Last modified: 2016-09-19 22:10:04 EDT
+++ This bug was initially created as a clone of Bug #968300 +++
7 RHEL5 TIP runes were killed by one of these tests, please investigate and fix the culprit as soon as possible.
Switch both tests to a CONFIRMED state in TCMS once they're no longer destructive.
list of test runs affected by this (see test-run notes for IDs of the killed recipes):
TR#64754, TR#64614, TR#64476, TR#64370, TR#64247, TR#64173, TR#64124
--- Additional comment from Robin Hack on 2013-05-29 08:28:14 EDT ---
I think, that is very nasty beakerlib implementation...
Store stdout and stderr to a file (mixed together, as the user would see it on a terminal) and set $rlRun_LOG variable to name of the file. !!!Caller is responsible for removing the file!!!. When -t option is used, the content of the file becomes tagged too.
If the -s option is not used, $rlRun_LOG is not modified and keeps its content from the last "rlRun -s".
rlRun -s "grep localhost:/usr /etc/mtab" 0 "Grep content of /etc/mtap"
This command has no output!
:: [ FAIL ] :: File '/dev/null' should contain 'noacl'
rlRun "rm -r $rlRun_LOG" 0 "Removing $rlRun_LOG"
:: [ PASS ] :: Removing /dev/null
--- Additional comment from Robin Hack on 2013-05-29 08:41:00 EDT ---
I wrote little workaround.
But this construction is still very dangerous.
*** This bug has been marked as a duplicate of bug 971783 ***
Sorry, got a bit confused. This is not a dup.
It is not a dup, but it is related. /dev/null should never be propagated to rlLog_LOG: when rlLog_LOG is set, it implies that DO_KEEP was set earlier, and that code should create a temporary logfile.
But the check for logfile creation was missing, /dev/null was used instead and was propagated in rlLog_LOG (in some cases rlRun even deleted it itself :)
I have modified rlRun so that /dev/null is only used in basic mode (no removal or propagation). With switches, when the temporary logfile creation fails, it is reported and switched to basic mode.
beakerlib-1.8-1.fc19 has been submitted as an update for Fedora 19.
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing beakerlib-1.8-1.fc19'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
beakerlib-1.8-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.