Date: Thu, 17 Dec 1998 08:11:49 -0600 From: Karl Denninger <karl@Denninger.Net> To: Eivind Eklund <eivind@yes.no>, David G Andersen <danderse@cs.utah.edu>, Alfred Perlstein <bright@hotjobs.com> Cc: hackers@FreeBSD.ORG Subject: Re: yup, found it (NFS) Message-ID: <19981217081149.A28502@Denninger.Net> In-Reply-To: <19981217150348.V68793@follo.net>; from Eivind Eklund on Thu, Dec 17, 1998 at 03:03:48PM %2B0100 References: <Pine.BSF.4.05.9812170116200.378-100000@bright.fx.genx.net> <199812170644.XAA03482@lal.cs.utah.edu> <19981217150348.V68793@follo.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19981217081149.A28502>