On Tue, Feb 9, 2016 at 8:51 AM, Randall S. Becker
<rsbecker@xxxxxxxxxxxxx> wrote:
[...]
> I've got those logs. Unfortunately, hoping for more details.
Me too. For example, a copy of those logs :-)
> The logs do
> show the test failure, but no details in failed-sshd.log indicating a
> specific problem. Some of the formats are a bit wonky but I can live with
> those. Since you mentioned NFS, which could have been constrained by UDP
> packet sizes, and this platform sometimes cannot read beyond 56Kb off disk
> (in some situations), it may be the read of regress/data that is failing.
> Any pointers where that is hiding so that I can verify that data is actually
> getting into sshd from the disk?
Unfortunately debugging test failures is a pain that I don't have a
good answer too.
One thing I do is edit regress/test-exec.sh to add a "set -x" at the
top and "exit 1" into the fail() function. Now when you run the test
at the point it fails you'll have the exact command that failed and
exits without cleaning up, leaving the keys and configs in place so
you can rerun the command in you shell, playing around with
truss/strace/whatever your platform has.
--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
