Hi,
Disclaimer: I am somewhat of a novice regarding Linux and server-side operations - additional explaining may be required!
We have a Perforce service running on a VM instance (Cent OS7) on Google Cloud Platform. It's been running with no problems for 8 months. This morning, none of us can establish a connection through P4V and we get the following error:
Connect to server failed; check $P4PORT.
connect: xxx.xxx.xxx.xxx:1666: WSAECONNREFUSED
In the SSH for the VM, both of these commands:
p4 configure set P4PORT=1666
p4 info
return the following:
Perforce client error:
Connect to server failed; check $P4PORT.
TCP connect to devel:1666 failed.
Name or service not known
Has the service stopped running or has it disappeared completely? Any help is appreciated.
Kind regards,
Dale


Connection to Server failed - WSAECONNREFUSED
Started by xonix, Nov 21 2019 12:40 PM
failed connection server service p4
2 replies to this topic
#1
Posted 21 November 2019 - 12:40 PM
#2
Posted 25 November 2019 - 08:53 PM
Double-check that your p4 client on the vm is actually connecting to the local server on 1666 (I don't know if "devel" is the right hostname):
If that still gives you a connection error, there's no p4d instance running on that port. If you can connect successfully with that, then p4d is at least running, but the network configuration between the client and server (whatever all those xxx.xx's point to) has gone awry.
p4 set P4PORT=1666 p4 info
If that still gives you a connection error, there's no p4d instance running on that port. If you can connect successfully with that, then p4d is at least running, but the network configuration between the client and server (whatever all those xxx.xx's point to) has gone awry.
#3
Posted 25 November 2019 - 09:20 PM
On the VM where the server should be running, run:
% ps ax | grep p4d
and see if you have any instances running (it appears you do not). If the daemon is running, you should see one or more lines that look like the following:
128119 ? S 0:00 /p4/18/bin/p4d_18 -p 5618 -r /p4/18/root -J /p4/18/logs/journal -L /p4/18/logs/log -q -d
128268 ? S 0:00 /p4/18/bin/p4d_18 -p 5618 -r /p4/18/root -J /p4/18/logs/journal -L /p4/18/logs/log -q -d
128417 ? S 0:00 /p4/18/bin/p4d_18 -p 5618 -r /p4/18/root -J /p4/18/logs/journal -L /p4/18/logs/log -q -d
3312818 ? S 0:15 /p4/18/bin/p4d_18 -p 5618 -r /p4/18/root -J /p4/18/logs/journal -L /p4/18/logs/log -q -d
3313015 ? S 11:40 /p4/18/bin/p4d_18 -p 5618 -r /p4/18/root -J /p4/18/logs/journal -L /p4/18/logs/log -q -d
3313016 ? S 12:40 /p4/18/bin/p4d_18 -p 5618 -r /p4/18/root -J /p4/18/logs/journal -L /p4/18/logs/log -q -d
You can look in the log file (typically /p4/1/logs/log but if you aren't using the SDP, look wherever you set thim up) to see if it crashed, was stopped by someone, or what. The last few lines should indicate something about what happened.
Run
% df -hP
to see if you ran out of disk space. If a filesystem shows Use% of 100%, that may be your problem.
% ps ax | grep p4d
and see if you have any instances running (it appears you do not). If the daemon is running, you should see one or more lines that look like the following:
128119 ? S 0:00 /p4/18/bin/p4d_18 -p 5618 -r /p4/18/root -J /p4/18/logs/journal -L /p4/18/logs/log -q -d
128268 ? S 0:00 /p4/18/bin/p4d_18 -p 5618 -r /p4/18/root -J /p4/18/logs/journal -L /p4/18/logs/log -q -d
128417 ? S 0:00 /p4/18/bin/p4d_18 -p 5618 -r /p4/18/root -J /p4/18/logs/journal -L /p4/18/logs/log -q -d
3312818 ? S 0:15 /p4/18/bin/p4d_18 -p 5618 -r /p4/18/root -J /p4/18/logs/journal -L /p4/18/logs/log -q -d
3313015 ? S 11:40 /p4/18/bin/p4d_18 -p 5618 -r /p4/18/root -J /p4/18/logs/journal -L /p4/18/logs/log -q -d
3313016 ? S 12:40 /p4/18/bin/p4d_18 -p 5618 -r /p4/18/root -J /p4/18/logs/journal -L /p4/18/logs/log -q -d
You can look in the log file (typically /p4/1/logs/log but if you aren't using the SDP, look wherever you set thim up) to see if it crashed, was stopped by someone, or what. The last few lines should indicate something about what happened.
Run
% df -hP
to see if you ran out of disk space. If a filesystem shows Use% of 100%, that may be your problem.
Also tagged with one or more of these keywords: failed, connection, server, service, p4
Usage →
APIs →
P4API.net connection.Credentials is always nullStarted by Lubos Suk, 01 Nov 2019 ![]() |
|
![]() |
||
Usage →
General →
How do I properly check into a remote Perforce server? Seems to only work locally.Started by FMastro, 11 Sep 2019 ![]() |
|
![]() |
||
Usage →
General →
What am I missing, trying to checking into and from a remote serverStarted by FMastro, 11 Sep 2019 ![]() |
|
![]() |
||
Usage →
Administration →
replica: switch between read-only and forward?Started by Miles O'Neal, 04 Sep 2019 ![]() |
|
![]() |
||
Usage →
General →
p4 command line to access multiple connections?Started by rasonage, 22 Aug 2019 ![]() |
|
![]() |
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users