HPUX error 232 Connection reset by peer

[Paul Thomson_2]

Hi,
On one of our servers the listener was unable to start. An error was seen in one of the logs showing...

HPUX Error: 232: Connection reset by peer

I have had a look on the website and have located the following doc.

netstat -a aborts producing core file. Oracle listener aborts. DocId: KBRC00003578 Updated: 11/29/00 9:00:00 AM

This details this error and highlights the cause as being an issue with DNS in /etc/nsswitch.conf. However, my nswitch file showed DNS on the following line.

hosts: files [NOTFOUND=continue] dns

Which is OK and also, netstat -a does not hang, produce a core file etc.

Apart from this has anyone ever come accross this problem when the listener starts ??

Our version of oracle is 8.0.6 and the server is running UX 10.20.

Thanks

[Armin Feller]

This error indicates that the routing table is incorrect for
either the default gateway or the host route to his local subnet.

[Armin Feller]

"Connection reset by peer" in oraserv indicates that the calling (sql)process has finished the connection. Are all recommended patches installed? Has you traced why, who aborded the connection to the listener? Please contact Oracle, perhaps they know this bug.

[Paul Thomson_2]

Many thanks.

I believe I have found a discrepancy in the routing tables.

Also, would you have a list of HP recommended patches for oracle (Or know where I could find one). We did patch the systems when oracle was installed. SoI guess we are at a level for HP recommendations. I just want to check.

[Armin Feller]

Please have a look at the Oracle installation guid, I don't know exactly the recommended patches ;-( You can then update the patches to the newest one in CustomerPatchManager in the ITRC.

[T G Manikandan]

Try setting the
set connect_timeout_listener=0 in listener.ora.($ORACLE_HOME/network/admin/listener.ora)
CONNECT_TIMEOUT_listener parameter sets the number of seconds that the listener waits to get a valid request.
by default it is 10 sec.

By setting connect_timeout_listener=0 the value is forever.


Try and revert back

[T G Manikandan]

Can you post your listener.ora and sqlnet.ora files?

What is there in the sqlnet.ora file.have you mentioned any nameserver configuration there.


REvert

[LE_1]

1/ Check the port of
the listener with netstat -an | grep XXX

Maybe another process uses it.

2/ Check the variable TNS_ADMIN
TNS_ADMIN gives the directory of the "listener.ora" file that Oracle uses when trying to start the listner.

If TNS_ADMIN is not set then Oracle uses $ORACLE_HOME/network/admin

Maybe it's the wrong "listener.ora" used.

[Paul Thomson_2]

Hi
The contents of the sqlnet.ora is
NAMES.DEFAULT_ZONE = tnteww.com

NAMES.DEFAULT_DOMAIN = tnteww.com

SQLNET.AUTHENTICATION_SERVICES= (BEQ,NONE)

NAMES.DIRECTORY_PATH= (TNSNAMES)

The contents of listener.ora

LISTENER =
(ADDRESS_LIST =
(ADDRESS= (PROTOCOL= TCP)(Host= ta367_1)(Port= 1521))
(ADDRESS= (PROTOCOL= IPC)(KEY= ta367_1))
)
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME= TPEDB01.tnteww.com)
(ORACLE_HOME= /oracle/app/product/8.0.6)
(SID_NAME = TPEDB01)
)
)
STARTUP_WAIT_TIME_LISTENER = 0
CONNECT_TIMEOUT_LISTENER = 10
TRACE_LEVEL_LISTENER = OFF


I donot think these are the cause as oracle is recycled most days on this system. This is mainly for a cold backup of the system. The listener has since restarted and these two files are as they were during installation , both dated May 2002. So I don't fancy touching those. I see more of an issue perhaps with the listener port being used.

Or maybe the netstat entry - Anyone agree ?

[U.SivaKumar_2]

Hi,

#hostname

Can you ping to the name shown by the above command ?

Have you put that server's hostname mapping in /etc/hosts or DNS ?.

Try this and observe whether the problem comes
edit /etc/nsswitch.conf
hosts: files

Have you got localhost entry in /etc/hosts file ?.

regards,

U.SivaKumar

[T G Manikandan]

Yes you are right.

There is some problem with resolving the service name using the names services on Oracle.

First we need to narrow down this problem.
We are trying to modify the file only to bring down the problem and understand it.

What you can do is

Take a copy of your sqlnet.ora and listener.ora files

Just modify as

sqlnet.ora
-------------


SQLNET.AUTHENTICATION_SERVICES= (BEQ,NONE)

NAMES.DIRECTORY_PATH= (TNSNAMES)

listener.ora
-----------------
LISTENER =
(ADDRESS_LIST =
(ADDRESS= (PROTOCOL= TCP)(Host= ta367_1)(Port= 1521))
(ADDRESS= (PROTOCOL= IPC)(KEY= ta367_1))
)
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME= TPEDB01)
(ORACLE_HOME= /oracle/app/product/8.0.6)
(SID_NAME = TPEDB01)
)
)
STARTUP_WAIT_TIME_LISTENER = 0
CONNECT_TIMEOUT_LISTENER = 20
TRACE_LEVEL_LISTENER = ON


//
Increase the timeout value.
taken off the domain entries so that the lookup is local//

Another is to
turned on the listener trace which should log into $ORACLE_HOME/network/listener.log file.
You can find the problems from the log file


Try this and revert


Thanks

[Paul Thomson_2]

ta367_1:/ # hostname
ta367_1
ta367_1:/ # ping ta367_1 -n 3
PING ta367_1: 64 byte packets
64 bytes from 164.39.197.40: icmp_seq=0. time=0. ms
64 bytes from 164.39.197.40: icmp_seq=1. time=0. ms
64 bytes from 164.39.197.40: icmp_seq=2. time=0. ms

----ta367_1 PING Statistics----
3 packets transmitted, 3 packets received, 0% packet loss
round-trip (ms) min/avg/max = 0/0/0

The server is /etc/hosts
164.39.197.40 ta367_1 ta367_1.tnteww.com


Also, the contents of nsswtich.conf

hosts: files [NOTFOUND=continue] dns

nslookup ta367_1 shows
ta367_1:/ # nslookup ta367_1
Server: ta367_1.ta.tnt.com
Address: 164.39.197.40

Name: ta367_1.ta.tnt

[Paul Thomson_2]

Hi all,

Thanks for your posts.

I have set up lsof to monitor the port 1521 to see if anything else is using the port when the listener starts, I am also going to reboot the server when time allows to try and clear the odd entry in the routing tables. A route delete does not work. As for the sqlnet.ora and listener.ora files I may wait to amend these as they have worked for a year so I do not think they are the cause. However, I have made note of the suggestions for changing them and will consider this if the issue re occurs. Also the listener has restarted 3 times this week OK, which mays me think something may have hogged port 1521 when the problem occured.

Many thanks so far for posts.

Paul