tags 607874 + pending patch severity 607874 normal thanks On Thu, 2010-12-23 at 14:46 +0200, Teodor wrote: > We're conducted some automated tests for 5000 connections to the CVS server > (for rebuilding some internal resources) and after increasing the maximum > number of connections to 60 we found that on 'stop' there were 182 'cvs' > processes still running (though cvsd has quit). We believe we have a bug in > our software too by not closing the connection to the CVS server, but also > the cvsd server should not leave processes behind after stop.
The hanging connections may also be a problem in cvs. I'm not sure but I guess some deadlock situations can occur in cvs. Even for read-only operations it uses locking. If you really need to support that many connections and read-only operation is good enough for you, you could have a look at http://arthurdejong.org/cvsd/faq.html#readonly which should increase performance significantly. > I had to 'pkill cvs' to have a clean start but this should be probably done > by the init script or by 'cvsd' process on exit. I've applied the patch below which should stop any remaining processes started by cvsd on stop. Note that this is not done on restart because it also terminates any ongoing transactions. This also means that you may leave processes hanging around after restart and stop. --- debian/cvsd.init 28 Feb 2010 19:45:46 -0000 1.18 +++ debian/cvsd.init 23 Dec 2010 16:14:43 -0000 @@ -58,6 +58,8 @@ $PFO \ --name cvsd log_end_msg $? + # kill any remaining child processes + [ -f "$PIDFILE" ] && kill -s TERM -`cat "$PIDFILE"` > /dev/null 2>&1 [ -n "$PIDFILE" ] && rm -f $PIDFILE ;; restart|force-reload) In general, I'm not sure that a daemon should terminate all ongoing requests on exit though. If a write operation is in progress, it may be better to complete the operation and leave the repository (including locks) in a consistent state. Anyway, the above patch will be in the next release. I don't think it's urgent enough to do quickly though and as such the fix will most likely not land in squeeze. Thanks for reporting this. -- -- arthur - [email protected] - http://people.debian.org/~adejong --
signature.asc
Description: This is a digitally signed message part
