Dumping core over NFS

Rick Macklem rmacklem at uoguelph.ca
Thu Aug 11 20:39:43 UTC 2011


Andrew Duane wrote:
> We have a strange problem in 6.2 that we're wondering if anyone else
> has seen. If a process is dumping core to an NFS-mounted directory,
> sending SIGINT, SIGTERM, or SIGKILL to that process causes NFS to
> wedge. The nfs_asyncio starts complaining that 20 iods are already
> processing the mount, but nothing makes any forward progress.
> 
> Sending SIGUSR1, SIGUSR2, or SIGABRT seem to work fine, as does any
> signal if the core dump is going to a local filesystem.
> 
> Before I dig into this apparent deadlock, just wondering if it's been
> seen before.
> 
The only thing I can tell you is that SIGINT, SIGTERM are signals that are
handled differently by mounts with the "intr" option set. For this case,
the client tries to make the syscall in progress fail with EINTR when one
of these signals is posted. I have no idea what effect this might have on
a core dump in progress or if you are using "intr" mounts.

There was an issue in FreeBSD8.[01] (for the "intr" case) where the termination signal could get
the krpc code in a loop when trying to re-establish a TCP connection because
an msleep() would always return EINTR right away without waiting for the
connection attempt to complete and then code outside that would just try
it again and again and... This bug was fixed for FreeBSD8.2.
Obviously it's not the same bug since FreeBSD6 didn't have a krpc subsystem,
but you might look for something similar. (ie. a sleep(...PCATCH...) and then
a caller that just tries again for it returning EINTR.

If you use "intr", you might also try without "intr" and see if that has
any effect.

Good luck with it, rick
> ...................................
> 
> Andrew Duane
> Juniper Networks
> o +1 978 589 0551
> m +1 603-770-7088
> aduane at juniper.net
> 
> 
> 
> 
> 
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to
> "freebsd-hackers-unsubscribe at freebsd.org"


More information about the freebsd-hackers mailing list