Jump to content

p4 monitor terminate never seems to work

  • Please log in to reply
25 replies to this topic

#21 p4rfong


    Advanced Member

  • Staff Moderators
  • 343 posts

Posted 26 October 2017 - 06:17 PM

Glad to hear that "p4 monitor terminate <pid>" now works for you!

#22 Mailman Sync

Mailman Sync

    Advanced Member

  • Maillist Aggregator
  • 2495 posts

Posted 11 November 2017 - 10:25 AM

Originally posted to the perforce-user mailing list by: Michael Mirman

I found this old thread and decided to add my 0.02 to it.

I can't say "p4 monitor terminate" never works for us now - I've seen some processes go away.
But not all.

Here's an example -- this is on an edge server:
-> p4 -p 1666 monitor show -l
2305 T mmirman    181:31:14 obliterate -ah //tasks/...Bhs.../...

Yes, I tried to terminate this process, which - if I recall correctly - was hung for a while and I decided I didn’t need to run it against an edge anyway.
P4 *marked* the process for termination, but that's it.
Sure enough, "ps" shows that process still running since November 3 - even though:

-> p4 -p 1666 configure show db.monitor.interval
db.monitor.interval:30 (configure)

This is for
Server version: P4D/LINUX26X86_64/2017.1/1534792 (2017/07/26)

Michael Mirman
MathWorks, Inc.

-----Original Message-----
From: perforce-user [mailto:perforce-user-bounces@perforce.com] On Behalf Of Sambwise
Sent: Wednesday, October 18, 2017 2:35 PM
To: perforce-user@perforce.com
Subject: Re: [p4] p4 monitor terminate never seems to work

Posted on behalf of forum user 'Sambwise'.

I haven't played with db.monitor interval, but from the description of it in
the KB article:

p4 configure set db.monitor.interval=30

which, for new commands processed by the server going forward, configures the
server to check for and terminate processes that have had  p4 monitor terminate
run  on them and are blocked on client input.   it sounds like it's checking
for commands that are in a very specific state, i.e. waiting on a client request
to complete (and it might be even more specific than that, e.g. it's
checking client-EditData requests but not, say, client-ReconcileAdd).

If you're able to track down the client that's running this reconcile
and do more investigation it might be possible to figure out exactly what
it's doing (if anything -- it wouldn't shock me if the client has in
fact gone away and the server somehow lost track of it).  If it's
a case of the reconcile command being really performance-intensive (e.g.
you've got a hundred potentially-renamed files that are all near matches for
each other and it's in combinatoric hell) that should be pretty easy to
diagnose/reproduce, and you can fix it going forward by tweaking configurables
to either make reconcile less fastidious or lower whatever other threshold is
currently set too high.

Please click here to see the post in its original format:
perforce-user mailing list  -  perforce-user@perforce.com
perforce-user mailing list  -  perforce-user@perforce.com

#23 p4rfong


    Advanced Member

  • Staff Moderators
  • 343 posts

Posted 16 November 2017 - 12:31 AM

Has the server been restarted?  Perhaps the command was running before db.monitor.interval was started.

Or maybe all the wildcards in

p4 obliterate -ah //tasks/...Bhs.../...

pegged a CPU and Perforce has not had a chance to get to the command.

#24 Sambwise


    Advanced Member

  • Members
  • PipPipPip
  • 1192 posts

Posted 16 November 2017 - 12:47 AM

View Postp4rfong, on 16 November 2017 - 12:31 AM, said:

p4 obliterate -ah //tasks/...Bhs.../...

If the command wedged in the mapping code I don't think monitor terminate would ever get a chance to kill it.  Are the map.joinmax configurables at their default levels?  That's pretty much the only guard you get against Map Joins of Doom.

#25 Miles O'Neal

Miles O'Neal

    Advanced Member

  • Members
  • PipPipPip
  • 214 posts
  • LocationAustin. Texas. Y'all.

Posted 12 August 2019 - 07:18 PM

View PostMiles O, on 16 October 2017 - 04:10 PM, said:

FWIW: We don't have to run terminate too often, but I find that at least half the time, I end up having to kill the process on the server. I don't have any data on which commands cause this. I've seen this since I started working with Perforce, including 2013.x, 2015.x or 2016.x, and 2017.1 .

I should note that we have had db.monitor.interval set to 30 for quite some time.I just now manually killed a process after waiting 5+ minutes after "p4 monitor terminate".

BUT... in this case, the user had started another sync (~4 days after the first one started), with the same client. I'm wondering if that is a factor. I know I have seen backed up processes for a user start running when a process is terminated or killed, and the next in line was related by client or paths. In this case the "p4 monitor show -s T -L" showed no lock files, but "p4 lockstat -c <client> showed "Read : meta/db".

(p4d 2017.1/1534792 on RHEL6.9)

#26 p4rfong


    Advanced Member

  • Staff Moderators
  • 343 posts

Posted 14 August 2019 - 01:59 AM

When you run "p4 lockstat -c <client>", this is fine for one process running from that client.  If there is more than one, then one process is probably waiting for the older process to finish.  If you are waiting for a process to terminate, you should see the T in "p4 monitor show -ael" for the process you want to terminate.  Do look at the CPU (top command, press 1 to look at each CPU) if "p4 monitor terminate <pid>" does not work.  Send us a support case support@perforce.com if "p4 monitor terminate <pid>" does not work and CPU is not at 100%.

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users