telnet login prompt delay after reboot

[David Child_1]

Unfortunately I don't have an answer for you, but if this happens again you might want to try the following:
1. telnet into the server (serverX)
2. on serverX look to see if telnetd is running

This of course won't find your problem, but it may help track it down. If it is running then the problem is most likely related to telnetd. If it's not running then start looking at the inetd process.

Or maybe it's a DNS problem! ...just kidding :)

Cheers,
David

[SIG. ENRICO CRIPPA]

Hello Andrew.
I got a similar case some days ago.
The cause was a delay on bind of rpc.cmsd at boot(you can check on /var/adm/syslog/syslog.log). This process uses rpc calls to function.
Rpcbind must be started before inetd for the rpc sockets to be opened correctly. Rpcbind is started in rc2.d S400nfs.core. Maybe Inetd is trying to start Rpc listener and can`t find correct socket.
So:
Could you check if /sbin/rc2.d/S400nfs.core is present on your system?
Did you make any change on the NFS configuration in the last weeks?

[Peter Lundquist_1]

Andrew,
I had the same issue with a customer recently, on 10.20.
Does the file /etc/nsswitch.conf exist? If so, does it contain all the lookup_types (left hand side)?

My customer only had this one line in his:
hosts: dns [NOTFOUND=return] files

I had him add the following:

networks: files
protocols: files
rpc: files
netgroup: files
services: files

This solved the delay before the login prompt.

The OS default is NIS first for most of these keys.
When not running NIS, all the keys need to be modified from default, to prevent a timeout from a nonexistant NIS. A missing key indicates the default condition.

On10.20, the defaults are in /usr/newconfig/etc/nsswitch.conf.
On 11.00, the defaults are in
/etc/nsswitch.hp_defaults.

I hope this helps,
Peter

[Andrew Maslin]

Italy, We have disabled NFS, both the Core and the Server. The scripts still reside on the server, but are not loaded at bootup. Is rpc.cmsd a required component/supporting service of telnetd? I've been wondering if RPC would have an affect on the telnetd service, but I have not been able to find any documented relationship between the two.

Peter, I don't have the /etc/nsswitch.conf file. I do have the nsswitch.compat, .files, .hp_defaults, .nis, and .nisplus files. If I don't have the nsswitch.conf file, do I need to modify anything (such as the nsswitch.hp_defaults file) to make sure that this is not causing the problem? I wasn't totally clear on that from your message. We are not running NIS here.

Thanks for the responses!

[Peter Lundquist_1]

Andrew,
Sorry for the lack of clarity. It's the first time I've posted.
In your case, with no /etc/nsswitch.conf file, the system defaults are what is listed in /etc/nsswitch.hp_defaults (which tries to use NIS).
Since you don't have NIS running, copy /etc/nsswitch.files to /etc/nsswitch.conf. If you're using DNS, modify the "hosts:" line in /etc/nsswitch.conf to "hosts: dns [NOTFOUND=return] files". See http://docs.hp.com/hpux/onlinedocs/B1031-90045/00/00/36-con.html
Let me know,
Peter

[Peter Lundquist_1]

Sorry, correction to last post.
The hosts line in /etc/nsswitch.conf should read: "hosts: dns files" or "hosts: files dns", depending on preference.
Leave out "[NOTFOUND=return]".

[Celso Medina Kern]

Hi Andrew,

What a difficult problem! I?d suggest tracing your telnet command with tusc
(an unsupported tool only for hp-ux 11.00) to see in what system call this command is stopping. At least you can have a better understanding of where it is hanging.

If even your localhost telnet from system console is hanging and you can ping hosts in your network, I?d say it is not a network/routing or name service problem. It seems more likely some system resource problem, even hardware. I think tusc can give you very good clarifications(give it execution permission and remove trailling caracters like ..txt). Execute tusc telnet ...

It would be nice to check from where name resolution is coming when the problem happens(ie: nslookup -d2 localhost), if you have route to the loopback interface and what conectivity you have to and from the network(level 2-linkloop, level 3-ping, services - telnet/ftp/rsh/etc).

Good luck!

[Andrew Maslin]

Hi all.

I have the solution to this problem. ITRC ITALY had the answer - I needed to re-enable the NFS core. I finally had a chance to reboot the server, and had the same problem as before, so I tried re-enabling NFS core and rebooted again and the problem was solved. I still can not find any link between RPC/rpcbind and telnetd or inetd, but it appears there is one. Thanks for everyone's help!

Incidentally, does anyone happen to know how I can go back and mark that post as the magic answer? I already assigned points to it earlier...

[IT Response]

I know this is an old post but I just recently had a client that ran into this problem. It took an unually long time for a telnet session to start after a reboot.

"telnet" is spawned out of
/usr/sbin/inetd. The problem is that something is causing inetd to initialize very slowly. The frequent cause of this is
that /usr/sbin/rpcbind has been turned off, usually as the result of a security
audit because the auditors consider it "insecure". This is typically done by
disabling /sbin/init.d/S400nfs.core at system startup.

The reason that this causes inetd to initialize very slowly is /etc/inetd.conf
often has some rpc programs which are spawned out of inetd.

If you want to run without
/usr/sbin/rpcbind, simply comment out the rpc entries in /etc/inetd.conf, for example:

#rpc xti tcp swait root /usr/dt/bin/rpc.ttdbserver 100083 1 /usr/dt/bin/rpc.ttdbserver
#rpc dgram udp wait root /usr/dt/bin/rpc.cmsd 100068 2-5 rpc.cmsd
#rpc stream tcp nowait nmbe /tmp/rpctest.ksh 436871681 1 inetd

But I would be very careful about what issues are caused by doing this, (as you have already run into one) and test thoroughly before commenting any them.

[Roberto Arias]

hi all please check DNS resolution ( in DNS server and /etc/hosts).

check the file /etc/nsswitch.conf for resolution of DNS or files ( if you don't have NIS, remove it of file)


check loopback adress (nslookup 127.0.0.1 and nslookup localhost)

regards