Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 9 Jul 2003 12:44:17 +0200 (CEST)
From:      Oliver Fromme <olli@secnetix.de>
To:        freebsd-fs@FreeBSD.ORG
Subject:   Re: NFS problem FreeBSD vs NetApp Filer using tomcat / java
Message-ID:  <200307091044.h69AiHte056291@lurza.secnetix.de>
In-Reply-To: <200307091117.aa12894@salmon.maths.tcd.ie>

next in thread | previous in thread | raw e-mail | index | archive | help
Ian Dowse <iedowse@maths.tcd.ie> wrote:
 > In message <200307090913.h699DnK3053575@lurza.secnetix.de>, Oliver Fromme writes:
 > > It is my understanding that the interruptible flag has only
 > > an effect when a signal is delivered to a process which is
 > > blocked on NFS I/O.  Or am I wrong?
 > 
 > Yes, the interruptible flag should only have an effect when the
 > process receives a signal while waiting on an NFS response. Maybe
 > it is possible that the progess is sending itself a signal? NFS
 > checks for SIGINT, SIGTERM, SIGHUP, SIGKILL and SIGQUIT.

Uhm.  Well.  It's a collection of Linux java processes
(about 30 of them), and the load on them is very erratic,
so it's a bit diffcult to find out what they do.  I guess
it's very possible that they send such signals to each
other or to themselves.  In the truss output of some of
the processes there are calls to linux_rt_sigprocmask()
and linux_kill().

I've also seen "SIGNAL 32" in the truss output, which
seems strange to me, because there is no such signal
number in <sys/signal.h>.  Well, maybe it's a Linux
signal.  I also see linux_kill(0xf6b3,0x20), and 0x20
is 32.  But I guess the NFS code does not check for
signal 32.  Or maybe the NFS code has a bug with non-
standard signal numbers >= 32?

 > If you are using the -s/soft option then that is quite different -
 > there are well-known effects where an unusually long delay from
 > the server can trigger occasional EINTR errors.

Nope, I never use the "soft" option.  I'm well aware
that soft mounts are evil.

I have now removed the intr flag from the mount.  Now
the only thing I can do is wait ...  If the problem
doesn't occur for a few days, I regard it to be solved.

Thanks a lot to all of you!

Regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200307091044.h69AiHte056291>