Posted on behalf of forum user 'G Barthelemy'.
[http://forums.perforce.com/index.php?app=forums&module=forums§ion=findpost&pid=15288]
Unfortunately, monitor terminate doesn't help, which is why I started this thread in the first place. You can see most of these are already marked for terminate, and the ones that have been running for 71 hours now were marked as such within the first hour, some much less than that. In previous jobs, I have used p4d -c "kill <PID>" directly on the server to handle these things, but in the current job, I do not have direct access to the Perforce server.
You will find that killing the client process will let the process on the server
terminate. I have always been wary of killing hanged syncs on the server for
fear of DB corruption, although I have to admit this is more out of superstition
than rationality, as by then the sync is no longer streaming data to the client
and it is no longer writing to the database, crucially. Using p4d -c "kill
<PID> " is a great idea. I must say that without access to the
server, even tracing the client PID (e.g. using netstat -p and matching ports)
is not going to be straight forward if the client is on a busy shared host (and
the chain is longer to follow if you use proxies and brokers).
I have found that there is always a valid explanation when a process squat the
monitor table even when p4-terminated but in the case of syncs I have never gone
to the bottom of the underlying reason, for lack of time. With syncs, it is
often caused by the client issuing a INT or TERM signal without actually exiting
the client process (often in scripts or client applications): the sync stops,
the peer p4d process does no longer access the database, but the socket pair
stays open and seem to keep each other alive (tcpdump / wireshark show that both
send each other short packets at regular interval and neither will timeout).
There is a TCP-ish flavour to this issue, my gut feeling is that it's not
necessarily just at the application layer. We seem to have this issue
exclusively with remote sites connecting to the Perforce server through TCP
accelerators, but that could be just a coincidence.
Now sometimes processes hang simply because they depend on others, so for
example just a few days ago a user caused a sync to hang. Then he proceeded to
delete his problematic client from P4V, not once but 4 times probably because
the client just would not go away, my guess is because there was a client lock
on it due to the sync (lockstat -c or -C is not related to database table
access, by the way, it just reports on client locks). He eventually exited P4V.
The 4 "client -d" commands remained in the monitor table (with no tcp
peer at the client end) and the client spec was still in the database. I made
him kill his script related to the sync. As soon as he did, all the related p4d
processes exited gracefully, including the 4 "client -d" (the first
one of which actually deleted the client spec from the DB).
Another scenario where processes can't be p4-terminated: someone is in the
middle of editing a spec and their window manager die for example. Again, this
is understandable (if the editor process did not exit) and is cleaner to resolve
at the client end...
I used to be a little OCD with processes that were just hanging in the monitor
table, but now I tend to let them go away by themselves. Maybe it's an age
thing :-) Clients eventually reboot their machines, etc... As long as your
server is not busy to the point where it threatens to run out of PIDs, of
course...
--
Please click here to see the post in its original format:
http://forums.perforce.com/index.php?/topic/3581-p4-monitor-terminate-never-seems-to-work