On Fri, 31 Jan 2003, D'Arcy J.M. Cain wrote:
> On Thursday 30 January 2003 12:07, Tom Lane wrote:
> > Perhaps the next thing to do is to strace (ktrace, trace, truss,
> > whatever system-call tracing utility you got) the postmaster and
> > child processes. If we could determine what system call is hanging up,
> > we might be a little closer to solving the mystery.
>
> Ktrace. Yes, am doing another test at the moment - using 100Mb to 100Mb and
> TCP option to the mount. Before I was using the default UDP and going 100Mb
> to 1000 Mb. If this works I will try my "guaranteed" fail next and will add
> ktrace. In fact, I will do that regardless.
Look at the -t option to ktrace. It controls what ktrace looks at
(syscalls, NAMEI lookups, etc.). Most importantly, you might want to NOT
include the 'i' option in there, which is in there by default. It logs the
data of all i/o transfers, which baloons the logs. While you may need the
data in the end, tracing w/o 'i' could show you the syscalls around the
failure which might be enough.
Take care,
Bill
