Description of problem: http://rhts.redhat.com/testlogs/62716/205783/1703592/TESTOUT.log :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ LOG ] :: Testing-NOT-Key-in-Keyring :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ PASS ] :: Unmount all sec\* dirs 2 keys in keyring: 1019058521: --alswrv 0 0 user: 6293455a29efa397 342556671: --alswrv 0 0 user: 13e8b1bc6090e91d :: [ FAIL ] :: Keyring is clear (Expected 0, got 1) 1 8424257 /CoreOS/ecryptfs-utils/Regression/bz501460-correct-error-msg-when-adding-to-full-keyring/Testing-NOT-Key-in-Keyring result: FAIL Version-Release number of selected component (if applicable): 75-5.el5.i386 How reproducible: sometimes Steps to Reproduce: do ~20 times: generate new SSL key use the new key to mount dirX done umount all dirs via: umount dir*/ Actual results: - sometimes two keys are left in the keyring - no error msg from umount Expected results: - all keys removed from keyring
which way you mount and umount this?
/sbin/mount.ecryptfs sec$keycnt/ sec$keycnt/ -o "key=openssl:openssl_keyfile=key$keycnt.pem:openssl_passwd=password,ecryptfs_cipher=des3_ede,ecryptfs_key_bytes=24,verbosity=0" &> $keycnt.out umount sec*/ See RHTS test case: /CoreOS/ecryptfs-utils/Regression/bz501460-correct-error-msg-when-adding-to-full-keyring
Is it reproducible? More info needed?
(In reply to comment #3) > Is it reproducible? no, I'm not able to reproduce this at all > More info needed? yes, whatever info that will help me reproduce this. How often is this reproducible for you? What platform?
I don't see it happening when the test is run standalone but only when is part of test-set scheduled via RHTS web UI. The problem therefor might be that the session keyring is dirty on test start already and because of this the keyring-isClean-subtest fails. I enhanced the test and will schedule it once more again.
Ou, yee. As I said two tests were leaving keys in keyring and they should not.