make test fails on xfs filesystem

Bug #672643 reported by Petr Lautrbach on 2010-11-08
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
libnih
Low
Unassigned
libnih (Debian)
Fix Released
Unknown
libnih (Ubuntu)
Medium
Dimitri John Ledkov
upstart (Fedora)
Fix Released
Medium

Bug Description

If there is used xfs fs on /tmp, upstart make check fails on:
BAD: wrong value for block file, got unexpected NULL
        at tests/test_conf.c:244 (test_source_reload_job_dir).

It's because in 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 like xfs, reiserfs and so on.

Related branches

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
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
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.

Petr Lautrbach (plautrba) wrote :

change detection of directory to lstat() and extend test_file to cover this case

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.

Changed in libnih:
status: New → Confirmed
importance: Undecided → Low
Changed in libnih:
status: Confirmed → Triaged
Dimitri John Ledkov (xnox) wrote :

brahms.debian.org is running / on xfs [1] and sees hence upstart test suite fails. [2]

I can confirm that the attach fix solves the problem with /tmp using XFS on both raring/ubuntu and stable/debian.

To reproduce the problem: simply mount /tmp as xfs.

[1] https://buildd.debian.org/status/fetch.php?pkg=procenv&arch=amd64&ver=0.18-1&stamp=1355134790
[2] https://buildd.debian.org/status/logs.php?pkg=upstart&arch=amd64

The attachment "change detection of directory to lstat() and extend test_file to cover this case" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

tags: added: patch
Changed in libnih (Ubuntu):
status: New → Triaged
importance: Undecided → Medium
assignee: nobody → Dmitrijs Ledkovs (xnox)
Changed in libnih (Debian):
status: Unknown → New
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package libnih - 1.0.3-4ubuntu13

---------------
libnih (1.0.3-4ubuntu13) raring; urgency=low

  [ Petr Lautrbach <email address hidden>, Dmitrijs Ledkovs ]
  * Fallback to lstat, if dirent.d_type is not available (not portable)
    (LP: #672643) (Closes: #695604)
 -- Dmitrijs Ledkovs <email address hidden> Tue, 11 Dec 2012 17:26:52 +0000

Changed in libnih (Ubuntu):
status: Triaged → Fix Released
Changed in libnih (Debian):
status: New → Fix Released
Changed in upstart (Fedora):
importance: Unknown → Medium
status: Unknown → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.