/tset/LSB.os/files/dev_tty/T.dev_tty 1
I've seen this test fail as UNRESOLVED in some contexts, and succeed on
others. In my testing, it's generally failed, although there are
occasions it succeeds. (For an example, see my tjreport archive at
http://hackers.progeny.com/~licquia/lsb/, specifically
tjreport-woody.200310140710.txt as contrasted to nearly all the
others.) These failures don't seem to vary between Debian 3.0 and
Debian testing, the two distributions I'm testing.
For reference, here's the journal:
10|640 /tset/LSB.os/files/dev_tty/T.dev_tty 18:44:00|TC Start, scenario ref 646-0
15|640 3.3-lite 1|TCM Start
400|640 1 1 18:44:00|IC Start
200|640 1 18:44:00|TP Start
520|640 1 00003893 2 1|child process was terminated by signal 1 (SIGHUP)
220|640 1 2 18:44:10|UNRESOLVED
410|640 1 1 18:44:10|IC End
80|640 0 18:44:10|TC End, scenario ref 646-0
I've been playing around with the test itself, and have found out a few
facts:
- The test generally fails the first time it's run. Subsequent runs
generally pass.
- The test nearly always passes when run under strace.
- By doing something that clears out the disk cache ("find / -type f
-print" or "cat /vmlinuz" or "find /usr -type f -print | xargs cat" have
done the trick), I can sometimes get the test to fail again once.
It seems to me that the UNRESOLVED results are the result of some race
condition in the test, and not any deficiency in the system; either
that, or the test can be fooled some of the time into not reporting a
real system deficiency, which isn't much better.
I've looked through the test source, but haven't found anything
interesting. Does anyone else have any ideas?
Reply to: