0

I'm already using P4V client and everything is fine, no connection error.

Error: I've got some SSL errors when I try to execute p4 command from Python. And it's random, If i re run the script, error isnt thrown everytime

From the client, the output is :

SSL receive failed.\nread: Operation succeed : WSAECONNRESET

From the server side logs, i've got :

Connection from 90.XX.XX.93:53929 broken. SSL receive failed. read: Connection reset by peer: Connection reset by peer

After le P4 Connection with p4.connect(), I run a p4.run_trust() command and the result seems ok

Trust already established

This error is trown doing a p4 fetch, of p4 edit myfile

Configuration

I'm starting my python script from the same computer running the P4V client. I'm using the same configuration ( user, workspace, url+port > ssl:p4.our-url.domain:1666 ). The SSL error happened with or without the P4V client started. The SSL certificate was generated during the Perforce Server installation and configuration. There is no apache server behind our subdomain p4.our-domain, so I can't test the SSL certificate using online SSL checker ( my network knowledge reach its limit there )

When i do a p4 info there is a "peer address", basically my IP with a random generated port (53929). What is this port ? Do i need to set a fixed port and redirect to my computer runing the script ?

Do you have any ideas where that error come from ? Is that a bad server configuration ( weird cause every p4v client in the office works). Do i need to establish and distribute a new certificate to all users of the P4Python script ?

Python 3.5.4

PyOpenssl 18.0.0

P4Python 2017.2.1615960

Thanks a lot for any advice.

ANSWER suggested by Sam Stafford

Sam was right, It seems I got a timeout. I was opening the P4 connection and connecting to the server on the script launch, then processing was launched to generate files before using p4 fetch/add/submit. Here is a workaround to reconnect in case on disconnection from the server

# self.myp4 = P4() was created on init, files are added
submited = False
maxTry = 5
while not submited and maxTry > 0:
     try:
         reslist = self.p4.run_submit(ch)
     except P4Exception as p4e:
         print(str(self.p4.errors))
         self.myp4.disconnect()
         maxTry -= 1
         self.myp4.connect()

     submited = reslist is not None and len(reslist) > 0

That works if you want to keep the connection open. I guess the best way to avoid timeout is to call P4.connect() method just before any P4.run_*method*() and close it after. Instead of wating for timeout to restart the connection.

Marcassin
  • 1,386
  • 1
  • 11
  • 21

1 Answers1

2

"Connection reset by peer" is a TCP error.

What does "connection reset by peer" mean?

Maybe your script is holding its connection open longer than P4V does, and a transient network failure during that period causes the connection to be reset? The best fix is probably to have the script catch the error, open a new connection, and pick up where it left off.

Samwise
  • 68,105
  • 3
  • 30
  • 44
  • I've already seen this TCP error but I didn't know it was the same error. I will try your solution and get back to you. Thanks – Marcassin Jul 17 '18 at 16:22
  • 1
    I did my test and you were right, catching the error and restating the connection fix the issue. I updated my question with code and ideas. Thanks a lot ! – Marcassin Jul 18 '18 at 14:18
  • As you note, closing the connection after you're done running commands is the ideal fix. You can actually end up running out of sockets on the server if every client is holding connections open that it's not using, so some admins will configure their network to automatically kill idle connections. – Samwise Jul 18 '18 at 19:14
  • 1
    fun fact: P4V used to hold its connections open as long as possible, and was eventually fixed to automatically close any connection it hadn't used in a couple of seconds, so as to avoid inadvertently DDOSing the server. This is a mistake that a lot of p4 client developers make in their first app. :) – Samwise Jul 18 '18 at 19:41