inetd strangeness

[Eric Ladner]

I have a system that refuses telnet and ftp (bogh get connection refused messages immediately). Normally, I'd say that the inetd daemon wasn't running and/or listeneing to those ports. The /etc/inetd.conf file looks sane.

Running 'inetd -c' on the system in question produces no messages in the syslog file. On other similar systems (inetd loging enabled on all systems), it at least produces "Rereading config.. Configuration complete" lines.

This system is a NIS+ client and is in trusted mode. Other systems locally configured with both NIS+ and trusted mode are working normally.

Any thoughts?

[James R. Ferguson]

Hi Eric:

Check for a 'var/adm/inetd.sec' file. See 'man 4 inetd.sec' for details.

Regards!

...JRF...

[Dietmar Konermann]

inetd -c or inetd -l should definitely provoke some logging to syslog (assuming that syslogd is working). Looks like your inetd is hanging or blocked on something.

Just trie to kill/restart it and watch for syslog messages. If still nothing happens, maybe inetd has indeeed problems to resolve e.g. services via NIS+?

Best regards...
Dietmar.

[Eric Ladner]

Follow up.

/var/adm/inetd.sec is default (matches my other systems with just a dtspc line)

Inetd is running. Telnetd is not running, nor is the port open in 'netstat -a | grep tel'

From further testing, no services served by inetd are functioning.

I reordered the /etc/nsswitch.conf to put files first for services. No change.

I have verified that NIS+ is working correctly (i.e. niscat services.org_dir and niscat hosts.org_dir work as expected).

Starting inetd with the -b option produces this in the syslog.log:

Nov 26 08:22:06 athena inetd[9695]: Connection logging enabled
Nov 26 08:22:06 athena inetd[9695]: Extended logging enabled
Nov 26 08:22:06 athena inetd[9695]: Entered for(;;) loop.
Nov 26 08:22:06 athena inetd[9695]: Reading configuration

That doesn't change the connection refused behavior, though.

I tried the inetd -b on a system that is working correctly and it produced a lot of messages (about each configured service).

[Dietmar Konermann]

Hmm... I recall these situations where inetd got stuck during startup/reconfiguration:

1) hostname/service resolving trouble
2) rpc entries in /etc/inetd.conf, but no rpcbind running
2) syslogd hung

Regards...
Dietmar.

[Sanjay_6]

Hi,

check and see if ytou have duplicate ip's on the network.

Hope this helps.

Regds

[Eric Ladner]

Do you recall how to clear the problem without rebooting the box :)

I just had a bout with a bad memory module that caused the box to reboot once a day or so. The users will probably come after me with torches and pitchforks if I bounce it again today.

[Dietmar Konermann]

I don't recall any inetd issue that really forced a reboot. :)

Of course sometimes rebooting is the fastest (brute-force) approach. But we are talking in the HP-UX forum here, aren't we? :)

Try what happens with a miminum /etc/inetd.conf, e.g. one that contains only the telnet configuration.

A system call trace (tusc) could also shed some light on this.

Best regards...
Dietmar.

[MANOJ SRIVASTAVA]

Are u able to ftp , telnet locally ? ie internally to the server . It may bne worthwhile to check the /var/adm/inetd.sec and see if there are any enteries . Also check for the ports to be free in /etc/services .




Manoj Srivastava

[L. Younes]

I had a problem with inetd not able to receive incoming telnet or anything else.
The problem was that in nsswitch.conf it looked for the services in NIS and if not found it returns, so I simply switched it to files (/etc/services), and it worked
Hope this helps

[Eric Ladner]

I've tried tusc. Tusc gets a memory error before producing any decent output to the log file (running with the '-f -o output.txt' options) :(

I'll try stipping down the inetd.conf.

I've verified the /etc/nsswitch.conf looks good and performs as expected. I have also reordered it to look at files first.

Telnet localhost and ftp localhost result in "Connection refused"

[Eric Ladner]

FYI.. this issue survives a reboot.

[Eric Ladner]

Ok.. it's got something to do with trusted system.

I did a pwconv and tried it again and still no dice.

On a whim, I unconverted (tsconvert -r) and magically it started working again.

I got a newer version of tusc which doesn't dump core any more so I'll do some comparisons between trusted mode and non-trusted mode and get back to this thread.

Thanks for the extra eyeballs.

Eric

[Dietmar Konermann]

Hi, Eric!

NIS+ with Trusted system and inetd... now the penny has dropped.

There is a known problem (JAGae42563) which is not resolved yet.

If you are hitting that then try this workaround:

- kill inetd.
- issue inetd -b
- issue inetd -b a 2nd time (not kidding!)

Best regards...
Dietmar.

[U.SivaKumar_2]

Hi,

Are you running Samba with SWAT enabled ? If so
it is known issue with broken SWAT .


regards,
U.SivaKumar

[Dietmar Konermann]

Eric,
any news regarding this inetd issue? I'm just curious about this!

Dietmar.

[John Eaton]

Eric,
It's been a few days since the last response, but if it helps...
I worked with HP back in July to resolve a problem identical to what you described here, as it applied to an upgrade of 10.20 to 11i. We're running trusted systems and did a test upgrade to 11i. Afterward inetd ceased to function. Lots of tests later the patch PHCO_27910 was released to fix the problem.
John

[Wodisch]

Hi,

maybe different forward and backward name resolution from that server onto that client's IP-address?

Just guessing,
Wodisch

[Dietmar Konermann]

Hi, John!

Just saw, that you found a fix for 11.11. Must have overlooked that...


libc patch PHCO_27910:
SR:8606245321 CR:JAGae11794 )
inetd(1M) daemon may hang on 11.11 trusted systems.
Inetd services will not work until "inetd -b" is run twice.

However for 11.00 this is still open.

Best regards...
Dietmar.