From owner-freebsd-hackers Thu Dec 17 06:12:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA00756 for freebsd-hackers-outgoing; Thu, 17 Dec 1998 06:12:16 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from Genesis.Denninger.Net (kdhome-2.pr.mcs.net [205.164.6.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA00746 for ; Thu, 17 Dec 1998 06:12:12 -0800 (PST) (envelope-from karl@Genesis.Denninger.Net) Received: (from karl@localhost) by Genesis.Denninger.Net (8.9.1/8.8.2) id IAA28507; Thu, 17 Dec 1998 08:11:50 -0600 (CST) Message-ID: <19981217081149.A28502@Denninger.Net> Date: Thu, 17 Dec 1998 08:11:49 -0600 From: Karl Denninger To: Eivind Eklund , David G Andersen , Alfred Perlstein Cc: hackers@FreeBSD.ORG Subject: Re: yup, found it (NFS) References: <199812170644.XAA03482@lal.cs.utah.edu> <19981217150348.V68793@follo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <19981217150348.V68793@follo.net>; from Eivind Eklund on Thu, Dec 17, 1998 at 03:03:48PM +0100 Organization: Karl's Sushi and Packet Smashers X-Die-Spammers: Spammers will be LARTed and the remains fed to my cat Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Dec 17, 1998 at 03:03:48PM +0100, Eivind Eklund wrote: > On Wed, Dec 16, 1998 at 11:44:57PM -0700, David G Andersen wrote: > > Lo and behold, Alfred Perlstein once said: > > > as an interrupt) is sent to a process waiting for an NFS server, > > > the corresponding I/O system call returns with a transient error. > > > (*1) Normally, the process is terminated by the signal.(*2) > > > > Right. This is simply having the system call return EINTR, one of the > > options I duscuss. However, it's not clear to me that this is the best > > option when the action was triggered by a close() on a file descriptor. > > Certainly, if it happens during a write, most processes know how to cope > > with it -- and the kernel does the right thing, returning EINTR. However, > > when flushing a dirty block during a close, and you get an intr, what do > > you expect to do? > > Retry the close(), or wait for program termination. Any daemon should > be careful about the return value from close(0. > > Or you could of course do something totally vile like this: > > Have the kernel fork the process. Have one of them continue the > close(), screw the file-descriptor in the other one and return OK. > When the sleep is over, finish the close and suicide. > > In _all_ cases you should allow SIGKILL to actually kill the process > _somehow_. Screw dirty blocks, I want to be able to kill processes > even if some stupid server in a locked room over there is dead. If I > didn't want to be able to make my system behave, I'd be running NT. Well, right now you can very easily end up with TOTALLY unkillable processes in the aforementioned tsleep (that I sent traces of last night); this is a minor issue by comparison. I am checking now to see if removing "intr" fixes BOTH conditions. So far so good, but it is way, way too early to know. -- -- Karl Denninger (karl@denninger.net) http://www.mcs.net/~karl I ain't even *authorized* to speak for anyone other than myself, so give up now on trying to associate my words with any particular organization. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message