[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Hung CVS server processes

From: Dan Peterson
Subject: Re: Hung CVS server processes
Date: Thu, 26 Sep 2002 19:21:15 -0700 (Pacific Daylight Time)

Well, I checked with a Solaris expert (actually a Sun SE) and he said
Solaris has always supported it.  He suggested I snoop the client to see
if it responds.   I checked on a couple and sure enough they did respond.

So this brings up another question...

Under what circumstances will a CVS client stay connected to the server
without doing ANYTHING?  Does this depend on the type of client?  Or are
there some commands that will stay connected?

The reason I ask is because whenever I execute a cvs command (Linux
command-line) and watch the server processes, the server processes always
goes away as soon as the command is complete.

So how come these processes are staying connected?

The ONLY packets that are exchanged between the client and the server are
a pair of keepalive packets (1 - server -> client, 1 - client -> server)
every 2 hours.

The server process has been sleeping in a read() call... is there someway
to determine how long it's been sleeping?

On Fri, 20 Sep 2002 address@hidden wrote:

> Larry Jones wrote:
> > So we're back to the unfriendly option -- it seems that Solaris
> > accepts the KEEPALIVE option but doesn't actually do KEEPALIVE
> > processing.  Like I said, I suggest finding some Solaris experts and
> > asking if there's a way to enable it.
>     This actually isn't all that surprising, given that KEEPALIVE is an
> optional component of TCP.  If you don't know already, KEEPALIVE has,
> since the early days of TCP, been the subject of great debate (this is
> largely because both sides of the debate have valid reasons reflecting
> differing operational scenarios.  In any case, as best I understand it
> (just tried to do some fact checking, but my key book is buried),
> accepting a KEEPALIVE option, but not actually performing keepalive
> may be (interpreted as) valid behavior.  Wish I could be a little more
> informative, but I thought I'd at least throw out the warning.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]