Troubleshooting socket errors
Connection reset by peer (10054 or 54) and Connection refused (10061 or 61) are the two most common socket errors.
Connection reset by peer (10054 or 54)
The “Connection reset by peer” socket error, which is 10054 (WSAECONNRESET) on Windows and generally 54 (ECONNRESET) on Unix and OpenVMS, indicates that a connection to the server has been closed. This could be caused by a fatal error on the server, the server stopping, a network problem, or even a connection problem.
|
1.
|
If the error has the form “connect:errno:error”, use vtxping (or synxfpng with the -x option) to test your ability to connect to the server. Otherwise, skip to step 2. The vtxping and synxfpng utilities print reports to the screen. This information can be used by your network administrator to resolve TCP/IP network socket communication problems. |
- If you can connect, then the network, the server, and the Synergy/DE OpenNet Server service (SynSQL) are working. Continue with step 2.
- If you can’t connect, make sure that the server is running, that the SynSQL service is running on the server, and that vtxping or synxfpng is using the port that the SQL OpenNet server uses.
For more information see vtxping utility and synxfpng utility.
|
2.
|
Check and correct the following, which may solve the problem if it is caused by network timing issues. |
- (Windows) If you’re using network licensing, make sure License Manager is configured as a network server.
- Make sure the server was rebooted after the Connectivity Series components were installed.
- (Windows) On the server, make sure the GENESIS_HOME environment variable is set in the environment or in opennet.srv (not at the user level).
- Check the system-level PATH on the server. It should include the connect directory.
- Use vtxnetd or vtxnet2 logging and check the resulting tcm_pid.log file. Then check the event log on Windows, syslog on Unix, or the operator console on OpenVMS. (For information on vtxnetd and vtxnet2 logging, see vtxnetd and vtxnet2 programs.)
- On the server, make sure the file(s) for the Synergy database driver (vtx4) are in the connect directory. On Windows, these files are vtx4.exe and vtx4.dll. On Unix, this is vtx4.so. On OpenVMS, this is vtx4.exe.
- Make sure there is no more than one vtxnet2 process running on the server. If there’s more than one, use vtxkill to kill the processes; then restart the service.
|
3.
|
If you are on Windows or Unix, run the dltest utility to make sure Connectivity Series DLLs or shared libraries are loading properly. |
|
4.
|
Make sure the dictsource and datasource lines in the connect file on the server have the correct settings. Then check the settings in the DSN. For example, if the DSN specifies a port, it should be the port that the SQL OpenNet server is running on. (If the SQL OpenNet server is running on the port that’s the default for the client, the DSN doesn’t need to specify a port. See Configuring Connectivity Series for more information.) |
|
5.
|
If you get this socket error again, use vtxnetd or vtxnet2 logging and check the event log on Windows, syslog on Unix, or the operator console on OpenVMS. |
Connection refused (10061 or 61)
The “Connection refused” socket error, which is 10061 (WSAECONNREFUSED) on Windows and is generally 61 (ECONNREFUSED) on Unix and OpenVMS, indicates that the xfODBC driver can’t make a connection to the SQL OpenNet server. The SQL OpenNet server may not be running, it may not use the port specified on the client side for the connection (see Port settings), or the host specified in the DSN may be incorrect.
|
1.
|
Use vtxping (or synxfpng with the -x option) to test your ability to connect to the server. (For more information see vtxping utility and synxfpng utility.) |
The vtxping and synxfpng utilities print reports to the screen. This information can be used by your network administrator to resolve TCP/IP network socket communication problems.
- If you can connect, then the network, the server, and the Synergy/DE OpenNet Server service (SynSQL) are working. Continue with step 2.
- If you can’t connect, make sure that the server is running, that the SynSQL service is running on the server, and that vtxping or synxfpng is using the correct port.
|
2.
|
Make sure the host name in the DSN is correct. |
|
On Unix, if you find that the SQL OpenNet server is running and the port is correct, it may be that server is terminating when the user that started it logs out. To run the server in the background and keep it running after you log out, use the nohup command: nohup vtxnetd -1958 &
For more information, see Starting SQL OpenNet for SQL Connection.
|