Date: Wed, 6 Nov 2002 01:10:03 -0800 (PST) From: Ruslan Ermilov <ru@FreeBSD.org> To: freebsd-bugs@FreeBSD.org Subject: gnu/44564 (was: Re: CVS pserver in FreeBSD 4.7-STABLE) Message-ID: <200211060910.gA69A3uJ089791@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR gnu/44564; it has been noted by GNATS. From: Ruslan Ermilov <ru@FreeBSD.org> To: Peter Wemm <peter@FreeBSD.org>, Robin Schilham <co9@xs4all.nl> Cc: stable@FreeBSD.org, bug-followup@FreeBSD.org Subject: gnu/44564 (was: Re: CVS pserver in FreeBSD 4.7-STABLE) Date: Wed, 6 Nov 2002 11:05:21 +0200 On Tue, Nov 05, 2002 at 11:26:26PM +0100, Robin Schilham wrote: > Ruslan Ermilov wrote: > >--9amGYk9869ThD9tj > >Content-Type: text/plain; charset=us-ascii > >Content-Disposition: inline > >Content-Transfer-Encoding: quoted-printable > > > >On Mon, Oct 28, 2002 at 01:00:52PM -0800, Kris Kennaway wrote: > > > >>On Mon, Oct 28, 2002 at 05:18:19PM +0500, Eugene M. Zheganin wrote: > >> > >>>Hi, all. > >>>=20 > >>>Ater installing FreeBSD 4.7-STABLE from cvsup I niticed the follwing > >>>problem: there is an CVS-repository on one of my FreeBSD boxes, and > >>>during it's work from time to time some cvs procecces appear; they do > >>>nothing, but their summary CPU load is enough high: > >>>=20 > >>> PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU C= > >> > >OMMAND > > > >>>4958 hunter 64 0 67144K 648K RUN 7:34 15.58% 15.58% c= > >> > >vs > > > >>>4939 alex 64 0 67144K 568K RUN 7:57 15.28% 15.28% c= > >> > >vs > > > >>>4960 hunter 64 0 67144K 10348K RUN 7:34 14.21% 14.21% c= > >> > >vs > > > >>>4971 hunter 64 0 67144K 66400K RUN 7:34 14.11% 14.11% c= > >> > >vs > > > >>>4919 alex 64 0 67144K 568K RUN 7:44 13.23% 13.23% c= > >> > >vs > > > >>=20 > >>I think this is a known bug in CVS: I'm CC'ing Peter on the reply > >>because he'll know more. > >>=20 > > > >I'm seeing this two, after upgrading our 4.5-STABLE box to 4.7-STABLE last > >Saturday. For example: > > > > PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU > > COMMA= > >ND > >65743 cvh 55 0 67316K 66768K RUN 220:23 85.84% 85.84% cvs > > > > > >>>There is at list one zombie process among them: > >>>=20 > >>># ps -ax | grep cvs > >>>4919 ?? Rs 7:50,15 cvs --allow-root=3D/usr/local/public/cvs pser= > >> > >ver > > > >>>4939 ?? Rs 8:02,97 cvs --allow-root=3D/usr/local/public/cvs pser= > >> > >ver > > > >>>4958 ?? Rs 7:40,10 cvs --allow-root=3D/usr/local/public/cvs pser= > >> > >ver > > > >>>4960 ?? Rs 7:39,88 cvs --allow-root=3D/usr/local/public/cvs pser= > >> > >ver > > > >>>4961 ?? Z 0:00,00 (cvs) > >>>4971 ?? Rs 7:39,87 cvs --allow-root=3D/usr/local/public/cvs pser= > >> > >ver > > > >>>97058 p1 S+ 0:00,02 /bin/csh -c ps -ax | grep cvs > >>>97205 p1 S+ 0:00,00 grep cvs > >>>=20 > >>>and I think the problem is in that zombie. > >>>=20 > >>>I can kill these procecces only by "killall -9 cvs". > >>>=20 > >>>When I type "kill -9 <zombie PID>" can't kill it. > >>>=20 > >>>I use CVS-repository with password auth, all binaries are from the > >>>base system; I launch cvs from inetd.conf with string > >>>=20 > >>>cvspserver stream tcp nowait root /usr/bin/cvs cvs --a= > >> > >llow-root=3D/usr/local/public/cvs pserver > > > >>>=20 > >>>may be I should change some of its flags ? > >>>=20 > >>>WBR Eugene. > >> > > > > See http://www.freebsd.org/cgi/query-pr.cgi?pr=gnu/44564 > I see this has already been fixed in the CVS repo: RCS file: /cvs/ccvs/src/server.c,v Working file: server.c head: 1.281 branch: locks: strict access list: keyword substitution: kv total revisions: 294; selected revisions: 1 description: ---------------------------- revision 1.280 date: 2002/10/04 19:56:01; author: scjones; state: Exp; lines: +13 -23 * client.c (get_responses_and_close, connect_to_pserver): Set to_server and from_server to NULL after freeing. * main.c (main): Clear server_active when finished. Also neaten up the SERVER_SUPPORT ifdef's. * server.c (do_cvs_command): Set protocol_inbuf, stderrbuf, and stdoutbuf to NULL after freeing. (server_cleanup): Free buf_from_net and buf_to_set and set to NULL. Also reset error_use_protocol. (server): Don't SIG_register server_cleanup. main_cleanup (which is already registered) outputs a fatal error which causes it to be called; registering it directly results in it being called twice. (cvs_output): Don't try to use buf_to_net or protocol if they're NULL. ============================================================================= So, the minimalistic patch (before -p1 is released) would look like this: %%% Index: server.c =================================================================== RCS file: /home/ncvs/src/contrib/cvs/src/server.c,v retrieving revision 1.13.2.3 diff -u -r1.13.2.3 server.c --- server.c 15 Oct 2002 20:24:38 -0000 1.13.2.3 +++ server.c 6 Nov 2002 08:57:47 -0000 @@ -5148,25 +5148,6 @@ } } -#ifdef SIGABRT - (void) SIG_register (SIGABRT, server_cleanup); -#endif -#ifdef SIGHUP - (void) SIG_register (SIGHUP, server_cleanup); -#endif -#ifdef SIGINT - (void) SIG_register (SIGINT, server_cleanup); -#endif -#ifdef SIGQUIT - (void) SIG_register (SIGQUIT, server_cleanup); -#endif -#ifdef SIGPIPE - (void) SIG_register (SIGPIPE, server_cleanup); -#endif -#ifdef SIGTERM - (void) SIG_register (SIGTERM, server_cleanup); -#endif - /* Now initialize our argument vector (for arguments from the client). */ /* Small for testing. */ %%% main_cleanup() -> error() -> error_exit() -> server_cleanup(). Cheers, -- Ruslan Ermilov Sysadmin and DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200211060910.gA69A3uJ089791>