help! can't telnet or ftp

[Roberto Martinez_2]

After modifying 3 kernel parameters, NFILE (from 12000 to 300000), NINODE (from 12000 to 300000) and npty (from 60 to 800), I can't telnet or ftp to the system. If I connect from the console, everything seems fine, inetd working, etc. Please help!

[Alex Lavrov.]

Do you have ping to/from the system?

what the output of:
netstat -in
lanscan
ifconfig lan

[Roberto Martinez_2]

yes, I can ping the server. From the console I see that inetd may be hang (only dies with a kill -9). but if I restart it, problem keeps on ...

[Ranjith_5]

Hi Roberto,

do
#tail -f /var/adm/syslog/syslog.log
on console. After that try an ftp and telnet attempt from other machine. See the mesg coming on syslog. Post the same.

Regards,
Syam

[Roberto Martinez_2]

Hi,

I can't see nothing on syslog when telnetting. but if I restart inetd, I can see "address already in use" for ftp and telnet services, so I must kill -9 inetd and restart (with same results). Do NFILE or NINODE have something to do with behaviour of telnetd or ftpd?

[Alex Lavrov.]

I think the problem is in values you assigned.

There is a connection between different kernel parameters and you can just assign some number:

ninode=nproc+48+maxusers+(2*npty)
nproc=20+(8 * maxusers)


I suggest you to take a realy close look at:
http://docs.hp.com/en/939/KCParms/KCparam.Nproc.html
http://docs.hp.com/en/939/KCParms/KCparam.Ninode.html

[Ranjith_5]

Hi,

Enable connection logging for ftp and telnet in /etc/inetd.conf using -l option.

do inetd -c

then try the same as last mentioned.

Kernel Parameter that you changed is nothing to do with this.

They can be explained as follows.

ninode
=============

This sets the inode cache size for HFS filesystems. The VxFS cache is configurable
separately (see vx_ninode below). Note, though, that the kernel configurable ncsize
that controls the Dynamic Name Lookup Cache (DNLC) and an NFS clientâ s rnode cache is based (by default) on ninode. Set ninode to 4000 if only /stand is on HFS; set it to
15000 or higher to be safe if you have many filesystems on HFS or to ensure ncsize is
large. Even higher values are useful for dedicated file servers.



nfile
============

The maximum number of concurrent file opens (that is, not the number of open files but
the number of concurrent open()s) on the system. The default formula usually works
this out to around this value, but 3000 is a pretty good starting point. If you have a lot offilesystem activity, you can bump this up higher without issues (a large Informix shop had this set to 80000!). Bump nfile up if you see high File Table utilization (>80 percent) in Glance (System Tables Report) or get "File table overflow" program errors. Use a similar approach for nflocks (max file locks). If you are configuring a big filesystem server
then you're more likely to want to bump up these limits.


Regards,
S

[twang]

Can the following command succeed(perform on your console connection),
# telnet 127.0.0.1

[Roberto Martinez_2]

From the console, I can't ftp to any server, but I can ping any of them. I don't want to try telnet because if my console session gets hung, I must reset the server (no option to clean shutdown). traceroute works fine. Name resolution: just hosts, no dns. users start to get angry. gasp.

[Joseph Loo]

hi,

just curious.

do u happen to have this file, /var/adm/inetd.sec? if so, do u mind checking if there are any deny to certain host or addresses?

also, if the gut feel is a kernel problem, u may like to revert back to original but as u may know, a reboot will be require?

regards.

[Ranjith_5]

Hi Robert,

Is there any /etc/resolv.conf and /etc/nsswitch.conf

pls post the same in case any.

Your name resolution can cause problems.

Regards,
Syam

[Ranjith_5]

Hi Robert,


One more thing..
What was the previous value for npty? Can u change it to 200 and see.Incase the above post doest helpful.value 800 is not really required. 200 would serve ur purpose.

Regards,
Syam

[Roberto Martinez_2]

answers:

inetd.sec: it's just the default server.
dns: configured not to use dns, just hosts.
npty was 60 before. First changed to 800, then to 200, then to 120, then 60 again (with reboot between changes).

New information: after about 20-25 minutes with the server started, telnet and ftp start to work. Reviewing syslog.log, it seems that inetd starts very very slowly. Anyway, ftpd and telnetd start at the beginning of inetd startup, but I'm not able to telnet or ftp after 20-25 min., apparently. Moreover, before they work I don't get an error but the telnet or ftp client remain hung (telnet client says:

telnet
Trying xxx.xxx.xxx.xxx...
Connected to .
Escape character is '^]'.

, and netstat -a returns telnet and ftp connections.
syslog.log does not yield errors related to inetd, just info messages. Apparently inetd semi-hangs (after starting, an inetd -k does not kill inetd, and inetd -c yields an "addres already in use" for ftp and telnet services.)

So, the question now is:
why takes inetd so long to start, which are the problems it has until it starts, where can I see errors apart from syslog.log?

Any hints?

[Alex Lavrov.]

Well, not likely, but it's a fast check.
R u shure that your network setting match switch settings?

Maybe after the reboot your setting were restored to the wrog values?

check with "lanadmin -x " (like lanadmin -x 0) and see if speed (full/half duplex) and autonegotiation (on/off) match on the server and on the switch it's connected to.

[Roberto Martinez_2]

good try, Alex, but I had checked that, everything seems fine.

[Alex Lavrov.]

Anyway you have nothing to lose, system is down, so maybe you can restore the previous values of the parameters and boot?

Just to be 100% sure that it is or not because of kernel parameters....

[Roberto Martinez_2]

well, in fact system is not down, once the 20-25 minutes have transcurred, users can ftp. I'll need to wait to this night to do any modifications. Anyway, I had reset the parameters (nfile, ninode and npty) to the original values before last reboot, but the original problem was not solved. I'm starting to think that the problem has always been there, having in mind that after the first 20-25 minutes everything seems to work fine...

[Alex Lavrov.]

Do you have all resent network patches installed?

If patches are not the issue, then if I were you, I would check with network team that everything is OK on heir side, that they don't see any weird entries in their logs and once I'm sure that switches/cables/whatever is OK, call HP support. Maybe there are some diagnostics they can run to check that everything is OK on the system including drivers and hardware.

[Roberto Martinez_2]

network admins have double checked everything, it seems ok for them...(and for me). Is there a command in HP-UX equivalent to the solaris' "snoop", so that I can sniff the packets?

[Alex Lavrov.]

tcpdump

you can see all the packages there:
http://hpux.connect.org.uk/hppd/hpux/Networking/Admin/tcpdump-3.8.3/

[Bill Hassell]

NFILE is fine at 300k (I've seen several million before) but NINODE should be reduced to a reasonable number, 4000 or less. As mentioned, NINODE is used only for HFS filesystems. On standard HP-UX, this is /stand with about 60 files or so. NINODE is a cahce for the HFS filenames and locations, so having it at 300k means a MASSIVE kernel increase with virtually all of the space empty and unusable. Now if you're using NFS heavily, you might bump it up to 10k or so to accomodate better NFS caching.

Now NINODE does not affect telnet or ftp but I would start by testing only with IP addresses (to bypass DNS). You can use nettl to produce traces on HP-UX or get a copy of Ethereal from the Internet Express CD or download from:

http://software.hp.com/portal/swdepot/displayProductInfo.do?productNumber=HPUXIEXP1111

[Gerhard Roets]

Hi Roberto

Using an estimate of 2k per ninode entry it would give you a memory load of 584MB if you have 300000 entries.

I would recommend you take it down a notch or two for a start as this can put some "memory pressure" on your machine.

If your machine starts paging due to this large memory load you will notce processes taking a long time to load.

I would also just for a sanity sake test both reverse and forward name lookup on th machin to see if everything is hunky dory.

HTH
Gerhard