Mark, It happens consistently on the hour and half hour. So I am guessing its a cvs client cronjob from somewhere. I checked the /var/adm/messages logs for the past few weeks on that server and there are no such entries to be found prior to the upgrade of server from 1.11.1p1 to 1.12.5. Since I have a dedicated filesystem for pserver tmp directory (-T in inetd.conf, now using --with-tmp in configure), I would have noticed the cvs-serv* directories bulding up in the tmp filesystem, so my guess is that the infinite loop core dump thing was fixed prior to 1.11.1p1. Which leaves the question as to why these messages are being generated with the 1.12.5 pserver?
Are there any backward compatibility issues with 1.12.5 pserver to older clients? Also, we got about 18 of the following in the /var/adm/messages as well today, again starting with the 1.12.5 upgrade.... no time pattern to these entries..... messages:Dec 30 09:29:14 batman cvs[12093]: [ID 666953 daemon.notice] bad auth protocol start: EOF messages:Dec 30 09:32:42 batman cvs[13517]: [ID 666953 daemon.notice] bad auth protocol start: EOF What would really help is having the cvs username (I use a non-root pserver) and the client machine/IP in the messages log for these errors. Hopefully a user and/or machine pattern will show up. From the looks of it, I should be able to use CVS_Username in main.c and add about another %s for CVS_Username variable to that error call. How would I print out the machine name/ip address of the client? Is it anywhere in the code (what I am afraid of is the account will end up to being the readonly anon account projects use for shared build/staging areas and website cron updates...) Any ideas on how these /var/adm/messages came into play on the pserver upgrade? Thanks, Mark Mark D. Baushke wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Mark, > > The message is generated by cvs_output(). > > Let us see what message it was trying to communicate to the client: > > cvs [server aborted]: received broken pipe signal > > This is being generated by the main.c main_cleanup() function > calling error(1,0,"received %s signal", name) where name is "broken pipe" > due to a SIGPIPE signal. Eventually this reaches cvs_output() and as it > does not appear to have a valid connection to the client, the error is > logged via syslog() if that is configured. > > So, something happened for one of your users while connecting to the cvs > server running on host batman. > > My guess would be that the user had just started a 'cvs' client command > and immediately killed the client side of the connection and what you > have in the syslog is a record of the server side not being able to send > anything back to the client. > > In the past, this kind of thing would usually leave a cvs process going > into an infinite loop trying to communicate with the client until it ran > out of virtual memory for its stack and died with a core dump. The > latest cvs does a better job of determining that there was a problem > communicating with its client and terminates more cleanly. > > Is it happening a lot? If so, you might want to modify the main.c error > call to include the userid that was running the command that got > interrupted and then ask that user or set of users what they have been > doing that might be causing the problem for you. > > If you have any particular suggestions for what information you would > like to see added to the syslog() error message, please let [EMAIL PROTECTED] > know. > > Thanks, > -- Mark __________________________________ Do you Yahoo!? Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003 _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
