Re: 1.12.5 pserver /var/adm/messages

[Mark]

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
address@hidden
> know.
> 
>       Thanks,
>       -- Mark


__________________________________
Do you Yahoo!?
Find out what made the Top Yahoo! Searches of 2003
http://search.yahoo.com/top2003