Hi, the workaround doesn't work on my computer. With this patch I don't see any change in the behaviour of the rpc.lockd. After a few hours the rpc.lockd stops with the signal 11 (only the process with the uid 0). Is there someone working on the PR kern/61122 or PR bin/61718? Jan On Tue, Feb 10, 2004 at 10:56:04AM +0100, Frode Nordahl wrote: > This is not a sollution, but I have run with this workaround since > friday without incident. > > I think there are two problems: > - freed items are sometimes not removed from the nfslocklist > - first element in blockedlocklist sometimes get wrong, causing a > infinite loop in retry_blockingfilelocklist() > On Feb 6, 2004, at 08:21, Andrew P. Lentvorski, Jr. wrote: > > >On Thu, 5 Feb 2004, Frode Nordahl wrote: > > > >>I also found this in send_granted(): lockd_lock.c:2161 > >> > >> debuglog("About to send granted on blocked lock\n"); > >> sleep(1); > >> debuglog("Blowing off return send\n"); > >> > >>Anyone know what sleep(1) is good for here? > > > >The sleep() statements near debuglog() stuff are to work around the > >fact > >that syslog has bugs where it arbitrarily and randomly eats messages > >when > >you start sending too much data at it too quickly. > > > >By slowing down the logging, all of the messages get recorded. -- [ gpg key: http://wwwds.physik.tu-berlin.de/~jan/jschlesn.gpg ] [ key fingerprint: 4236 3497 C4CF 4F3A 274F B6E2 C4F6 B639 1DF4 CF0A ] -- It's better to reign in hell, than to serve in heaven...Received on Fri Feb 13 2004 - 00:22:18 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:43 UTC