At Wed, 3 Jun 2009 20:54:16 +0000 (UTC), mlelstv%serpens.de@localhost (Michael van Elst) wrote: Subject: Re: NFS > > tron%zhadum.org.uk@localhost (Matthias Scheler) writes: > > >> I'm using -i but it doesn't seem to help (too much). > > >I personally don't think that this is a good idea. I e.g. don't want an > >editor to get an error if the NFS server is unreachable and throw away > >an hours worth of changes as result. > > -i doesn't make your editor see errors unless it traps interrupting > signals. Based on the documentation I thought it was the other way around (indeed probably most editors do trap all or most interrupting signals, eg. vi does, though it does try to make sure to do so in a way such that interruptable system calls will return EINTR, IIUC). From the "NFS Implementation" section of "The 4.4BSD NFS Implementation": An interruptible mount (-i option) checks to see if a termination signal is pending for the process when waiting for server response and if it is, the I/O system call posts an EINTR. Normally this results in the process being terminated by the signal when returning from the system call. This feature allows you to ``^C'' out of processes that are hung due to unresponsive servers. The problem with this approach is that signals that are caught by a process are not recognized as termination signals and the process will remain hung. * Unfortunately, there are also some resource allocation situations in the BSD kernel where the termination signal will be ignored and the process will not terminate. (the footnote I think may explain the unkillable "df" issue) It all sounds like a cop-out though -- the NFS client code shouldn't really be trying to figure out whether a signal is a termination signal or not. -- Greg A. Woods Planix, Inc. <woods%planix.com@localhost> +1 416 218-0099 http://www.planix.com/
Attachment:
pgpdaBOntaQlY.pgp
Description: PGP signature