Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Forums
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-20-2002 02:03 PM
06-20-2002 02:03 PM
socket.h
Being ignorant in the HP-UX 11.0
environment, I have been looking at increasing the SOMACONN value in socket.h.
Can anyone shed some light here?
1. I would like to increase the number of ftp connections allowed.
2. What values have you used?
3. Will changing this value accomplish what I am asking on the OS side or are there other parms to consider?
It looks as though this file is used in a kernel rebuild as well as C compiles (from other posts). Thus, I do not have a level of comfort in changing the value.
Appreciate any and all input.
Thanks.
dl
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-20-2002 04:17 PM
06-20-2002 04:17 PM
Re: socket.h
Are you reaching the maximum number of ftp sessions allowed? Are ftp sessions being refused? The default ftp that ships with HP-UX 11.0 determines the maximum number of ftp connections via the kernel parameter "NPROC". NPROC by default is based on "maxusers". To change these the easy way, you can use SAM to edit the kernel paramters to meet your needs and then let it rebuild the kernel and reboot the box.
Now lets make sure we're on the same page here. Are you referring to the amount of outgoing ftp connections using the ftp client that ships with HP-UX 11.0 or are you referring to the amount of incoming ftp connections via the ftpd server?
The above refers to the amount of ftp traffic outgoing. I'm a bit confused on how Oracle comes into play here, other than it running on the server where these ftp connections are taking place.
Hope that helps.
-Mike
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-21-2002 08:08 AM
06-21-2002 08:08 AM
Re: socket.h
The problem, rare as it is, affects incoming ftp connections.
I believe our nproc setting is tuned correctly as I see no outgoing problem.
I am basing my questions on documentation from metalink.oracle.com and on the occasional failure to connect we see on mainframe jobs opening a connection to the HP-UX server.
We have found no reason for the failure to connect as when the mainframe job is re-run all is fine.
Currently, SOMAXCONN is at the default of 20.
I am looking for input on ramifications of upping the value.
Thanks for the input Mike.
dl
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-21-2002 08:40 AM
06-21-2002 08:40 AM
Re: socket.h
Ok, then we're looking at the ftpd server itself accepting connections from clients. If you're using HP-UX 11.0, I think it ships with wu-ftpd, running from inetd. Check the following:
1. Check your /var/adm/syslog/syslog.log for errors from ftpd.
2. Check to ensure that you have ftpd logging errors and such to your syslog via:
/etc/inetd.conf
Which should contain a line similar to:
ftp stream tcp nowait root /usr/lbin/ftpd ftpd -l
The -l tells it to log information to the syslog. You can also add a -v to tell ftpd to log even more information for troubleshooting purposes.
Note - if you make changes to /etc/inetd.conf you'll need to have inetd re-read it's configuration:
inetd -c
3. Verify the port that ftpd is running on:
more /etc/services
The above should contain a line for ftp on port 21.
4. If all else fails do a:
man ftpd
This should give you all the related configuration files.
How many users are trying to connect at one time? Do you have a rough estimate?
Hope that helps.
-Mike
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-21-2002 08:51 AM
06-21-2002 08:51 AM
Re: socket.h
I forgot to mention the /etc/ftp/ftpaccess file that might contain a limit statement in it, such as:
limit all 10 Any /etc/msgs/msg.dead
Where 10 equals amount of concurrent connections allowed.
Here is a good resource for more wu-ftpd information:
http://www.landfield.com/wu-ftpd/
Good luck.
-Mike
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-21-2002 09:05 AM
06-21-2002 09:05 AM
Re: socket.h
I have a good feel for this being the problem when it does occur which, as mentioned, is seldom.
Have you made a change to this include file?
Or, is the doc from Oracle all wet?
dl
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-21-2002 09:11 AM
06-21-2002 09:11 AM
Re: socket.h
The access file shows the following three limit lines:
limit local 20 Any /etc/msgs/msg.toomany
limit remote 100 SaSu|Any1800-0600 /etc/msgs/msg.toomany
limit remote 60 Any /etc/msgs/msg.toomany
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-21-2002 09:27 AM
06-21-2002 09:27 AM
Re: socket.h
What Oracle documentation are you referring to in particular? I searched for "SOMAXCONN" on technet.orcale.com in the 8i documentation section and came up empty.
Please provide us with an excerpt of the documentation so we can put it into context for you. I would doubt that Oracle would reocmmend that you alter socket.h manually.
-Mike
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-21-2002 09:54 AM
06-21-2002 09:54 AM
Re: socket.h
Note is note specificly HP-UX 11.0 but does address the problem with the same parm used in 11.0.
dl
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-21-2002 10:12 AM
06-21-2002 10:12 AM
Re: socket.h
Are you getting any errors on the machine that is doing the FTP when the connection fails?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-21-2002 11:15 AM
06-21-2002 11:15 AM
Re: socket.h
That is correct but according to HP docs, as well, it does apply to ftp socket connections.
On the ftp note, all we see is a connection failure. It is extremely difficult to re-create since an immediate re-run works fine.
Our thought is it is tied to this
parm and the activity on the OS at the time.
For the oracle perspective we see it affecting process connections.
Am I making this any clearer?
dl
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-21-2002 12:35 PM
06-21-2002 12:35 PM
Re: socket.h
After reading your attached document and searching around the web for more info, I've come up with the following that might assist you.
First, lets look at each problem on it's own, since the ftpd and Oracle listener process are different processes accpeting incoming connections on the same TCP/IP stack.
FTPD:
1. If you are receiving error messages in /var/adm/syslog/syslog.log that state that ftpd has reached it's maximum number of connections, then alter:
/etc/ftp/ftpaccess
And change the limit parameter to allow more concurrent connections for each class (local/remote). This will ensure you're not reaching a barrier with the ftpd configuration itself.
Oracle listener:
1. The document discusses the listen() system call, being the root cause of the problem you may or may not be experiencing. Thus, one would assume you might be reaching a full listen queue from the OS side, but I don't know of any way to edit something like this as this is a hard coded part of the sockets and TCP/IP code. However this may be accomplished using 'adb', but I would wait before looking into that further.
2. I would start by looking at some samplings of the output of 'netstat -a' on the server in question and times when you are experiencing this problem. This should give you and idea of the sockets and their states with the various clients trying to connect.
3. I would also ensure that you have the latest patches for HP-UX 11.0 with regards to transport and steams.
Also, ensure that you feel confident that your underlying network is providing adequate response times from the HP-UX server and it's clients. I would also open up a support call with HP to provide them with this information, so they can escaliate it up the chain.
Someone like Rick Jones should be able to provide you with the right information about how to solve your problem, if indeed you are filling up the listen() queue.
Hope that helps, good luck!
-Mike
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-21-2002 12:50 PM
06-21-2002 12:50 PM
Re: socket.h
When and if we have the direct cause and resolution, I will post.
dl
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-21-2002 01:02 PM
06-21-2002 01:02 PM
Re: socket.h
HTH
Marty < Who had to wait a week to be told his MeasureWare for AIX problem was IBM's problem>