From owner-freebsd-fs@FreeBSD.ORG Wed Jul 9 03:44:20 2003 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7753337B401 for ; Wed, 9 Jul 2003 03:44:20 -0700 (PDT) Received: from lurza.secnetix.de (lurza.secnetix.de [212.66.1.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6287E43FB1 for ; Wed, 9 Jul 2003 03:44:19 -0700 (PDT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (vidqfm@localhost [127.0.0.1]) by lurza.secnetix.de (8.12.8p1/8.12.8) with ESMTP id h69AiHB5056292 for ; Wed, 9 Jul 2003 12:44:18 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.12.8p1/8.12.8/Submit) id h69AiHte056291; Wed, 9 Jul 2003 12:44:17 +0200 (CEST) Date: Wed, 9 Jul 2003 12:44:17 +0200 (CEST) Message-Id: <200307091044.h69AiHte056291@lurza.secnetix.de> From: Oliver Fromme To: freebsd-fs@FreeBSD.ORG In-Reply-To: <200307091117.aa12894@salmon.maths.tcd.ie> X-Newsgroups: list.freebsd-fs User-Agent: tin/1.5.4-20000523 ("1959") (UNIX) (FreeBSD/4.8-RELEASE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: NFS problem FreeBSD vs NetApp Filer using tomcat / java X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2003 10:44:20 -0000 Ian Dowse 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 . 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.