Bug 562815

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.