Databases
cancel
Showing results for 
Search instead for 
Did you mean: 

cannot accept connection to the port oserr 233

Vineet Mehrotra
Occasional Advisor

cannot accept connection to the port oserr 233

Hi All,

We are using Informix Dynamic Server 7.31UD6 on HP-UX 11.0.

We get these error messages in our log quite often and all the new connections comes to standstill.



14:51:47 listener-thread: err = -25573: oserr = 233: errstr = : Network driver
cannot accept a connection on the port.
System error = 233.

So by looking into the error file it says ENOBUF issue.

Also if I issue dbaccess at that time it just takes too long to bring the screen.

I really want to get into the root cause of this as this has been a long outstanding issue in our environment and I don't have good idea about what factors contribute to this.

What to look for when we face situation like this and what tuning can be done at the os level or database level to avoid this to reocur.

Here are the entries from our onconfig file

NETTYPE soctcp,3,500,NET # Configure poll thread(s) for nettype
NETTYPE ipcshm,1,64,CPU # Configure poll thread(s) for nettype

Here is the tail of the onstat -u command

228 active, 256 total, 247 maximum concurrent ( it goes up to 350 concurrent at times)

Here is the some kerner parameters set on the box

maxfiles 120
maxfiles_lim 1024
nfile 15341

maxdsiz 32768
maxssiz 2048
maxtsiz 16384

Also here is the typical output of sar -v on the system


00:00:00 text-sz ov proc-sz ov inod-sz ov file-sz ov
01:00:00 N/A N/A 365/8212 0 3122/9540 0 2864/15341 0
02:00:00 N/A N/A 358/8212 0 9540/9540 0 3052/15341 0
03:00:00 N/A N/A 360/8212 0 4216/9540 0 3140/15341 0
04:00:00 N/A N/A 367/8212 0 9540/9540 0 3295/15341 0
05:00:00 N/A N/A 362/8212 0 6724/9540 0 3421/15341 0
06:00:00 N/A N/A 345/8212 0 3106/9540 0 3726/15341 0
07:00:00 N/A N/A 346/8212 0 3109/9540 0 3785/15341 0
08:00:00 N/A N/A 343/8212 0 3079/9540 0 3873/15341 0
08:20:00 N/A N/A 329/8212 0 3751/9540 0 3886/15341 0
08:40:00 N/A N/A 338/8212 0 3074/9540 0 3892/15341 0
09:00:00 N/A N/A 348/8212 0 3047/9540 0 3951/15341 0
09:20:00 N/A N/A 355/8212 0 3121/9540 0 3982/15341 0


I would appreciate if someone can guide me through this problem.

Thanks,

Vineet
15 REPLIES
Navin Bhat_2
Trusted Contributor

Re: cannot accept connection to the port oserr 233

What is the cumulative ARPA transport patch on your system?
hari jayaram_1
Frequent Advisor

Re: cannot accept connection to the port oserr 233

Vineet,

This can be due to a number of reasons

1. Ndd parameter

tcp_conn_request_max

2. Please have a look at the document below

http://www1.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000065953792

Could you please advice what kind of a server this is


Vineet Mehrotra
Occasional Advisor

Re: cannot accept connection to the port oserr 233

Thanks guys for quick response on this.

The database server is Informix Dynamic Server 7.31 UD6 and the unix server is

HP-UX B.11.00 U 9000/800

Also I am not able to open the documnet link you send ..

I want to know what is the blocking factors and how to validate it
Vineet Mehrotra
Occasional Advisor

Re: cannot accept connection to the port oserr 233

What is the cumulative ARPA transport patch on your system?

I don't know how to check that..Please advise. Thanks!
hari jayaram_1
Frequent Advisor

Re: cannot accept connection to the port oserr 233

Vineet,

I have pasted the contents below.

11.0:accept() returns ENOBUFS(No buffer space available) DocId: WTECKBRC00005581 Updated: 9/26/02 5:23:00 AM

PROBLEM
From 11.0, application server - Informix / Oracle / inetd /
etc - sometimes causes "No buffer space available" or ENOBUFS.
This didn't happen on 10.X. Why does this happen and what can be
done to prevent this error?
RESOLUTION
How this symptom can be seen:
=============================
The symptom can be seen with any 'server' type application
which calls accept() system call. Inetd can also cause this
error on 11.0. Some customers see this with Informix / Oracle
and other major application's server daemon. The errno(see
man errno, for more details) is defined like:

#define ENOBUFS 233 /* No buffer space available */

in /usr/include/sys/errno.h. The way of printing this error
varies. Some application can just leave '233' in its log file.
Sophisticated application would call perror(3C) or
strerror(3C) to print the corrsponding error message(for
ENOBUFS, the message is "No buffer space available").

What ENOBUFS means:
===================
In many cases, ENOBUFS just means there's no sufficient
memory available and the system(kernel) can not allocate
any more. This is general definition and in most of case
such situtaion can be regarded as transient resource
shortage. And each system call can add some more information
in man pages if there're some specific meaning for each
error. Application will usually retry the operation when it
detects this error from a system call since it indicates
there's transient resource shortage.

When you look at accept(2), you will find the following
explanation:

[ENOBUFS] No buffer space is available. The accept() cannot
complete. The queued socket connect request is
aborted.

Why 11.0 accept() can cause ENOBUFS?
====================================
The description has not been changed at 11.0. However,
the implementation of accept() system call was changed
at 11.0(Transport stack has changed drastically due to
STREAMS based TCP/IP). And it can return -1 with
errno=ENOBUFS based on the condition of "the queued socket
connect request is aborted". Here, this means the transport
stack received RST just after SYN was received. If RST comes
before accept() is done, this situation can happen.

On 10.X, if this happens, the connection was just silently
dropped.

How this error should be handled?
==================================
If this can be seen with existing application, just ignore
the error. Since this can happen when we receive RST just
after SYN, the connection request is anyway cancelled.
There should be no serious problem.

If the application aborts with this error situation, it
should be re-written so that it will retry accept() system
call. ENOBUFS is usually indicating transient error. So,
aborting the application just by seeing this error once
should not be proper action. The application should be
modified so that it gets more robustness.

PORTABILITY ISSUE:
==================
UNIX Networking Programming Vol 1 Second Edition
(Richard Stevens, ISBN 0-13-490012-X) mentions this in
"5.11 Connection Abort before accept Returns" (page 129).
It says what happens is implementation dependent. HP-UX
11.0 returns ENOBUFS.
ALT KEYWORDS
Informix Oracle ENOBUFS
You may provide feedback here
Navin Bhat_2
Trusted Contributor

Re: cannot accept connection to the port oserr 233

#swlist -l patch|grep -i ARPA

also what is the output of oncheck -cl?

Vineet Mehrotra
Occasional Advisor

Re: cannot accept connection to the port oserr 233

here is the output about the ARPA patch

# PHNE_23456 1.0 cumulative ARPA Transport patch
# PHNE_26771 1.0 cumulative ARPA Transport patch
# PHNE_28538 1.0 cumulative ARPA Transport patch

Also I have gone through the document but it didn't say much about the exact solution of the problem. In our environment this problem exists for 2-3 hours at times intermittently which is not acceptable and then all of sudden goes away and not appear for months but its a pain
Navin Bhat_2
Trusted Contributor

Re: cannot accept connection to the port oserr 233

what is the output of oncheck -cl?

As the doc points out, you may want to check your application. Why are the RST's coming in? Again this is not necessarily a problem. The accept cannot complete thats why you get this error. Check to see why you are getting RST's that will help.
hari jayaram_1
Frequent Advisor

Re: cannot accept connection to the port oserr 233

Vineet,

When this problem happens do you know what your memory utilization is. If as per Navin there is no issue with the application then best option would be to add some more memory to the system and increase your buffers.
Vineet Mehrotra
Occasional Advisor

Re: cannot accept connection to the port oserr 233

The memory utilization was ok when this problem occurred. We have around 1GB free memory on the system and recently we added memory on the box so I don't think this is a memory issue.

Also there is no commands like oncheck -cl on informix. Are you talking about onstat -c.

How to see how many RSTs are coming?
Navin Bhat_2
Trusted Contributor

Re: cannot accept connection to the port oserr 233

Sorry typed it wrong. It is to verify the indexes "oncheck -cI", sounds strange but I have seen this happen.
Vineet Mehrotra
Occasional Advisor

Re: cannot accept connection to the port oserr 233

We run the oncheck utility every weekend and it completes successfully every time. Don't see any integrity issue in the database.
Navin Bhat_2
Trusted Contributor

Re: cannot accept connection to the port oserr 233

You can use tools like nettl (man nettl) for detailed transport analysis. You may want to call in to hp support for further help. But basically I would think this is an harmless message and have the application folks reinitiate a connection when there is a abnormal disconnect.
hari jayaram_1
Frequent Advisor

Re: cannot accept connection to the port oserr 233

Vineet,

If you have added memory and if you have so much free memory then that cannot be the issue. I would like some more information.
Can you cut and paste your /stand/system. Also if you can do a "swlist -l fileset -a state > /tmp/patch" and attach the copy. Please remove everything which might identify your server.
Vineet Mehrotra
Occasional Advisor

Re: cannot accept connection to the port oserr 233

Hi Hari,

Here is the tunable parameters value from /stand/system

* Tunable parameters

STRMSGSZ 65535
max_thread_proc 66
maxdsiz 0X08000000
maxfiles 1024
maxswapchunks 2048
maxuprc 256
maxusers 1024
msgmax 32768
msgmnb 32768
msgmni 100
msgseg 7168
msgtql 256
npty 128
nstrpty 60
num_tachyon_adapters 5
semmni 4096
semmns 16384
semmnu 2048
semume 256
shmmax 0X11FFFFFFF
shmmni 4096
shmseg 4096

Let me know if you need more information.

Also please find the patch list you asked for.

Thanks once again for all your support on this.