Distribution: Gentoo OS: Linux-3.8 glibc: 2.15 tools/tests/test-save.log --- 1..14 ok 1 /save/test_file_write ok 2 /save/test_file_exists ok 3 /save/test_file_bad_directory ok 4 /save/test_file_overwrite ok 5 /save/test_file_auto_empty ok 6 /save/test_file_auto_length ok 7 /save/test_write_with_null ok 8 /save/test_write_and_finish_with_null ok 9 /save/test_file_abort not ok 10 /save/test_directory_empty # rmdir() failed: Directory not empty # in teardown() at test-save.c:75 ok 10 /save/test_directory_empty not ok 11 /save/test_directory_files # rmdir() failed: Directory not empty # in teardown() at test-save.c:75 ok 11 /save/test_directory_files not ok 12 /save/test_directory_dups # rmdir() failed: Directory not empty # in teardown() at test-save.c:75 ok 12 /save/test_directory_dups ok 13 /save/test_directory_exists not ok 14 /save/test_directory_overwrite # rmdir() failed: Directory not empty # in teardown() at test-save.c:75 ok 14 /save/test_directory_overwrite
Thanks for the bug report. Unfortunately I can't reproduce it here. Could you run the test-save executable under strace, and post the output as an attachment? That would help us get to the bottom of the issue.
$ ./test-token 1..17 ok 1 /token/load ok 2 /token/flags ok 3 /token/path ok 4 /token/label ok 5 /token/slot ok 6 /token/not-writable ok 7 /token/writable-no-exist ok 8 /token/writable-exists not ok 9 /token/load-found # assertion failed (ret == 1): (0 == 1) # in test_load_found() at test-token.c:385 ok 10 /token/load-already ok 11 /token/load-unreadable p11-kit: couldn't stat path: /tmp/test-module.ySG21H/test.cer: Unknown error ok 12 /token/load-gone ok 13 /token/reload-changed ok 14 /token/reload-gone ok 15 /token/reload-no-origin ok 16 /token/write-new ok 17 /token/write-no-label
Created attachment 82743 [details] test-token.strace
Out of interest, what file system is /tmp on the system which is running the tests?
Created attachment 82903 [details] [review] Make tests work on file systems with block size directories On certain file systems the size of the directory does not change when adding a file. This caused the tests to fail. Make the tests wait more than a second in certain tests to get the mtime to change.
Attachment 82903 [details] pushed as 2e7952e - Make tests work on file systems with block size directories
> Out of interest, what file system is /tmp on the system which is running the tests? /tmp is rootfs, no separate filesystem, ext4. $ uname -a Linux localhost 3.8.6-hardened #1 SMP PREEMPT Fri May 10 18:51:59 IDT 2013 x86_64 Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz GenuineIntel GNU/Linux $ /lib/libc.so.6 GNU C Library stable release version 2.15, by Roland McGrath et al. Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 4.5.4. Compiled on a Linux 3.4.0 system on 2012-10-21. Available extensions: C stubs add-on version 2.1.2 crypt add-on version 2.1 by Michael Glad and others Gentoo patchset 23 GNU Libidn by Simon Josefsson Native POSIX Threads Library by Ulrich Drepper et al Support for some architectures added on, not maintained in glibc core. BIND-8.2.3-T5B libc ABIs: UNIQUE IFUNC For bug reporting instructions, please see:
> wait more than a second in certain tests to get the mtime to change. I think that this will result in timing issues much harder to find. Consider using alternate method which is not time sensitive.
I can confirm that this was indeed the root cause.
(In reply to comment #8) > > wait more than a second in certain tests to get the mtime to change. > > I think that this will result in timing issues much harder to find. Consider > using alternate method which is not time sensitive. I am open to ideas, but so far nothing solves this completely without tradeoffs. Thought process: Given * This is about the trust module detecting when data in the file system changes and pulling in new anchors/blacklist information. * This detection happens only on a new C_OpenSession for performance reasons. * Applications using the trust module cache all sorts of stuff (ssl sessions, certificate information, what have you). Therefore * To guarantee that new trust data is actually used the process will have to be restarted in most cases anyway. * So it seems the current method is good enough for opportunitistic reloading of data that in reality rarely changes. * The tests force this issue, and therefore additional work arounds are not surprising. We could have an additional method that the tests use to expire the opportunistic reload information.
If this applies to tests only - not critical. But I suggest to use inotify/fam/gamin if you rely on filesystem content changes.
(In reply to comment #11) > If this applies to tests only - not critical. > > But I suggest to use inotify/fam/gamin if you rely on filesystem content > changes. This is a significant overhead. Each process which has p11-kit loaded would be monitoring files that almost never change.
(In reply to comment #12) > (In reply to comment #11) > > If this applies to tests only - not critical. > > > > But I suggest to use inotify/fam/gamin if you rely on filesystem content > > changes. > > This is a significant overhead. Each process which has p11-kit loaded would > be monitoring files that almost never change. It is less overhead than pulling status... and will enable you to issue slot change event. Timing issues are even worse... :)
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.