In response to a question about getting additional information from within
an *info script:
On Sat, 21 Jun 2003 Larry Jones wrote:
You can run cvs -n status (the -n causes it to ignore the lock that's
in place for the in-progress commit).
Has the -n option always ignored the lock?
I've run
On Tue, 11 Mar 2003 [EMAIL PROTECTED] wrote:
On Tue, 11 Mar 2003 [EMAIL PROTECTED] wrote:
What is the exact content of your $CVSROOT/CVSROOT/loginfo file?
DEFAULT (/home/cvsuser/cvs-scripts/cvs-mail-checkin-notifications %{sVv}
/home/cvsuser/cvslogs/commit-mailer.log 21)
I believe the
A user has asked the following question (see below). I don't believe
there's a way to do what he wants, but thought I'd check to make sure.
I was trying to use tag info to report changes to a particular tag and
what files it changes. It works well except for the fact that it
reinvokes the
Is there a way to start the CVS server (pserver) so it can be run through
gdb?
I want to be able to debug the server process from the very beginning, but
the best I can do is after inetd has forked off the cvs server process I
can attach to the process with gdb using the PID. Problem is, this is
On Fri, 27 Sep 2002 [EMAIL PROTECTED] wrote:
Dan Peterson writes:
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 only time I can think
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
We constantly find old CVS server processes hanging around and I'm
wondering if there's any reason they don't timeout.
For example, at the moment there's over 15 processes that have been
running (or rather sleeping) for more than 24 hours... the oldest of these
has been sleeping for almost 20
On Thu, 19 Sep 2002 [EMAIL PROTECTED] wrote:
Dan Peterson writes:
Why doesn't either the CVS server process or the TCP connection timeout?
Good question. The CVS server uses the KEEPALIVE socket option, if
available, to detect broken connections. KEEPALIVE tells the system
On Fri, 20 Sep 2002 [EMAIL PROTECTED] wrote:
Dan Peterson writes:
But the interesting thing is, none of the current list of 15 procs
older than 24 hours logged one of these KEEPALIVE message. At least I
assume I should see the same process id in /var/adm/messages as the
current hung
Has the locking behavior changed between 1.11 and 1.11.2?
Specifically, we've noticed locks for an entire tree seem to hang around
until the entire tree has been modified. The 1.11 behavior seemed like it
would only lock a specific directory at a time.
In other words, the observed behavior for
We're in the process of setting up a new server for CVS access and for
various fallback, redundancy and recovery reasons the directory part of
the users CVSROOT environment variable must point to a symlink.
During testing of the system, we discovered commands don't always work
right. In
On Thu, 7 Mar 2002, Larry Jones wrote:
2. Two processes; the first has a parent of inet and it's child
seems to be spinning and using lots of CPU (after about 34 hours one
process has used about 24 hours of CPU). The sockets associated with
the first process are in an IDLE state.
I'm investigating applying Stephen Cameron's .trunk + .origin patch
and find myself wondering a couple things about CVS Releases:
1. What's the odds of this patch getting included in the main CVS source
so it doesn't need to be reworked each time there are changes to the
source?
When I asked
On Thu, 7 Mar 2002, Larry Jones wrote:
Dan Peterson writes:
I've seen ESTABLISHED and IDLE.
That's interesting, there is no official TCP state called IDLE. I
wonder what it means? Certainly both states imply that the connection
is alive and well as far as the system can determine.
I
Is this just a problem with Debian CVS?
http://www.debian.org/security/2002/dsa-117
I'm assuming Debian CVS comes from the standard CVS source, so couldn't
this be a problem on other platforms?
___
Info-cvs mailing list
[EMAIL PROTECTED]
On Mon, 4 Mar 2002, Larry Jones wrote:
Dan Peterson writes:
While investigating an issue with CVS server processes (pserver
v1.11), I noticed a number of processes that didn't appear to be
talking to a client anymore and had been hanging around for many hours
or even days.
What
On Mon, 4 Mar 2002, Stewart Brodie wrote:
I did investigate modifying the cvs software to put the username and
client IP address in its process name so we could see with 'ps' which
client is involved with which server process
You don't need to go to all that trouble... just get lsof and run
While investigating an issue with CVS server processes (pserver v1.11), I
noticed a number of processes that didn't appear to be talking to a client
anymore and had been hanging around for many hours or even days.
Some of the processes had a parent process ID of 1 which tells me the
process
Recently, I've been investigating a problem with left-over lock files on
our CVS server (pserver).
During my research, I wanted to see how a client responds when a lock file
exists. I assumed if I manually created a lock dir called #cvs.lock or a
lock file called #cvs.rfl.host.pid or
19 matches
Mail list logo
