Description of problem: When I try to rebuild upstart with /tmp - XFS filesystem, build failed on test Testing conf_source_reload() with new job directory (see log). If tmpfs of ext3 mounted on /tmp, build finishes ok, but after install and reboot, boot process freezed on init start (I have / XFS too). Version-Release number of selected component (if applicable): upstart-0.6.3-7.fc13.src.rpm last working version: upstart-0.3.11-3.1.bcx.src.rpm How reproducible: 100% Steps to Reproduce: 1. mount /tmp XFS 2. try to rebuild rpm 3. see failed test. 4. mount /tmp tmpfs 5. rebuild rpm - OK -- only for mazo: 6. PREPARE for boot error (copy old init) 7. upgrage 8. reboot -- see boot hang. 9. restore old init Actual results: dont work on XFS. Expected results: work on ANY good filesystem (may be clean request for FS abilities). Additional info:
Created attachment 389514 [details] build log with error
Only interesting thing about upstart and filesystems is its use of inotify. I've never used XFS, does it support inotify?
Seems to work tty3: inotifywait /tmp tty2: touch /tmp/zzz tty3 out: /tmp/: CREATE zzz
Are you certain this is specific to xfs? I changed the TEST_FILENAME() macro to use /mnt/testfs instead of /tmp, tried ext3, ext4, and xfs, re-running "make check-TESTS" in the init/ dir, and it seems to fail on each one.
Hm, or more simply, mount different filesystems on /tmp :) Well, I get failures with ext4 /tmp as well as with tmpfs on /tmp Anton, any chance you can try ext3 or ext4 in your setup? I'm inclined to distrust this "make check" ... but then I can't tell what it's doing, w/ all the macro cleverness. Just for examples... xfs: Testing nih_dir_walk() ...with no filter ...with filter ...with stat failure and no error handler BAD: wrong value for logger_called, expected 1 got 0 at tests/test_file.c:934 (test_dir_walk). /bin/sh: line 4: 28248 Aborted ${dir}$tst FAIL: test_file Testing nih_watch_new() ...with file ...with directory only ...with directory and sub-directories ...with create handler ...with non-existant path ...with error with sub-directory BAD: wrong value for logger_called, expected TRUE got FALSE at tests/test_watch.c:504 (test_new). /bin/sh: line 4: 28253 Aborted ${dir}$tst FAIL: test_watch Testing nih_main_write_pidfile() ...with successful write ...with overwrite of existing pid ...with failure to write to temporary file BAD: wrong value for ret, expected less than 0 got 0 at tests/test_main.c:417 (test_write_pidfile). /bin/sh: line 4: 28258 Aborted ${dir}$tst FAIL: test_main ext3: Same 3 failures. -Eric
Are you runninng make check under root user? Some libnih and upstart tests fail with euid == 0. Typical reason is that test tries if it is able to read file without read right on file or "x" right on directory and root user can always read or walk through these files/directories
Comment #5 probably refers to another issue than original report see my previous comment
Ok, yes, I was running it as root. Sorry for that noise ... -Eric
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle. Changing version to '13'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Tested 'make check' with some filesystems, mounted in /tmp: good: ext[234], tmpfs, btrfs, nilfs2 bad: xfs, jfs, reiserfs Seems, that it may be a unimplemented feature in some filesystems (first of journaled?). Failed code dont give enougth information about feature: test_conf.c:243 file = (ConfFile *)nih_hash_lookup (source->files, filename); after this statement 'file' is 0.
Dave, not sure what's going on on this one but just randomly cc'ing you on xfs-related bugs ;)
The main issue (do nothing) dissapear after some of initscripts updates. Seems, that upstart must require initscripts >= 9.12 ? But failed tests may indicate obscure kernel bug, related to first journaled filesystems. Sorry, but I don't know how to make a testcase: tests from upstart is not a vivid thing. If it don't affect to other programs, bug may be closed.
Do the upstart tests still fail on recent kernels & recent upstart?
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This is issue of libnih library. There is a test if an entity is a directory based on struct dirent returned by readdir(3): nih/file.c:644 if (filter && filter (data, subpath, ent->d_type == DT_DIR)) but used item d_type is not supported by all filesystem.
Created attachment 458805 [details] don't use dirent.d_type This patch changes detection of directory from dirent.d_type to S_ISDIR(statbuf.st_mode))) and adds one more test to cover this bug.
I've pushed and built in rawhide fixed libnih-1.0.2-3.fc15 package [1] I've done some tests myself but it would be nice if you test it too. [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=2597092
Seems to fixed in libnih-1.0.2-3.fc15. Propose to close. It may be usefull to emit warning while compiling code with dirent.d_type.