[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnumed-devel] Re: Bug and workaround identified

From: catmat
Subject: [Gnumed-devel] Re: Bug and workaround identified
Date: Sun, 27 Feb 2005 16:55:21 +1100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041231

J Busser wrote:

At 9:24 AM +1100 2/27/05, catmat wrote:

The timeout for save apparently is sent to 3600 seconds
in twiki conf . ( presuming this includes signalling the application that a user wants to
edit, the user typing , and then pressing save).

The above is partly correct. It provides the means to prevent any other user editing that particular wiki page for at least one hour after an initial user has edited that page (to reduce the chance of conflicts) EXCEPT that a user can release the lock manually, for example if they think someone else may want to work on the page and do not themselves mind being locked out of editing for an hour. During that hour, TWiki considers all edits by that user part of the same "revision" in order to reduce the amount of versioning required to be tracked.

I got one consistent way of stopping a block.
If I edit DevelRefMisc from the web page, and then view processes with ps -A
there is no new processes.
When I try to save it , and it blocks, a process called oops appears on doing ps -A in ssh. there is a perl(?) program called oops in the twiki (?cgi) /var/www/twiki/bin directory. If I kill the oops process in ssh, the web page responds, and the editing gets committed.

So I think there is some resource that oops tries to acquire , and can't , and blocks waiting for it.
Not sure what oops does though.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]