Hi, 2010/12/23 Arthur de Jong <adej...@debian.org>: > 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.
No, we need to also write some file back but thanks for the suggestion. >> 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) I don't think this is correct. First the 'cvsd' process which you are trying to terminate with 'kill' is already stopped by start-stop-daemon call. Anyway, this is a workaround and I still recommend to do it properly from 'cvsd' itself. Second, the execution of 'kill -s TERM' doesn't kill child processes but only the given process ID from $PIDFILE. Third, there is a typo there that makes the execution invalid: | $ PIDFILE=/var/run/cvsd.pid | $ kill -s TERM -`cat "$PIDFILE"` | -bash: kill: 17418: invalid signal specification > 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. I was thinking that it should terminate all the child processes. Now I think it is more important to avoid data loss or service interruptions. I'm not sure that killing cvs child processes could cause inconsistencies, but if child processes can finish up their current work without the 'cvsd' parent being present I would tag this bug "wontfix" and close it. Thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
