All,
The STP framework has been giving errors on various socket related
system calls that do not show up under regular LTP runs. I have
seperated the problems to a method that doesn't involve the STP so I
know it's not a STP specific thing, it's just how the STP runs the LTP
suite.
When you run the LTP from the console you have a controlling terminal
open and everything is happy. When you run it like this:
ssh remote-host -l root "path_to_ltp/runall.sh"
You get the errors I am now trying to kill. The difference as far as
I can tell is when done with ssh - there is no controlling TTY unless
you give the -t option to SSH and then the errors do not show up.
SO...
A strace of a invalid run gives the following (major snippage):
For the first fall (Gives a FAIL correctly)
accept(400, 0x804dd10, [0]) = -1 EBADF (Bad file descriptor)
For the second call (Gives a correct FAIL with an incorrect errno value)
accept(0, 0x804dd10, [0]) = -1 EINVAL (Invalid argument)
The fact that the second call is attempting to open fd[0] seems to be
the only difference here. The first accept attempt does what it should
regardless, the second fails correct with -EBADF when it has a terminal,
and incorrectly as seen above with -EINVAL when it doesn't have a
temrinal.
According to ACCEPT(2):
" In addition, network errors for the new socket and as defined for
the protocol may be returned. Various Linux kernels can return
other errors such as EMFILE, EINVAL, ENOSR, ENOBUFS, EPERM,
ECONNABORTED, ESOCKTNOSUPPORT, EPROTONOSUPPORT, ETIMEDOUT. The
value ERESTARTSYS may be seen during a trace. "
Help Please.
I need to know if -EINVAL is a correct response when fd[0] in a headless
environment. If so, the LTP needs to be adapted to this, if not things
get ugly.
Thoughts?
Should we use ISATTY(3) to determine what errno value we expect in these
cases?
-Nathan Dabney
Open Source Development Lab
|