Date: Tue, 29 Aug 2006 13:28:00 +0400 From: "Alexey Karagodov" <karagodov@gmail.com> To: "Peter Jeremy" <peterjeremy@optushome.com.au> Cc: Michael Abbott <michael@araneidae.co.uk>, freebsd-stable@freebsd.org Subject: Re: NFS locking: lockf freezes (rpc.lockd problem?) Message-ID: <c7aff4ef0608290228k1f674f3dp4321e957160fcaa@mail.gmail.com> In-Reply-To: <20060829075034.GA727@turion.vk2pj.dyndns.org> References: <200608281220.k7SCKoJW054182@lurza.secnetix.de> <20060828124935.G62656@saturn.araneidae.co.uk> <20060829075034.GA727@turion.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
it's all is very good, but what can you say about to fix problem with rpc.lockd ??? 2006/8/29, Peter Jeremy <peterjeremy@optushome.com.au>: > > On Mon, 2006-Aug-28 13:23:30 +0000, Michael Abbott wrote: > >I think there is a case to be made for special casing SIGKILL, but in a > >sense it's not so much the fate of the process receiving the SIGKILL that > >counts: after all, having sent -9 I know that it will never process > again. > > Currently, if you send SIGKILL, the process will never enter userland > again. > > Going further, so that if you send a process SIGKILL, it will always > terminate immediately is significantly more difficult. In the normal > case, a process is sleeping on some condition with PCATCH specified. > If the process receives a signal, sleep(9) will return ERESTART or > EINTR and the code has to then arrange to return back to userland > (which will cause the signal to be handled as per sigaction(2) and > the processes signal handlers). In some cases, it may be inconvenient > to unwind back to userland from a particular point so PCATCH isn't > specified on the sleep. > > -- > Peter Jeremy > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c7aff4ef0608290228k1f674f3dp4321e957160fcaa>