Telnet/Password Delay??????/

[Rebecca Harding]

Since Friday we have been getting delayed on telnet sessions into our K210 (10.20), takes about 45 seconds to a minute to get a login, then it takes about 30 secs after the password is input.

On Friday, we had a problem, with a very NICE user, writing an astronomically HUGE file, and /var went 100%. We cleaned up and rebooted, but since then network is delaying.

Pinging anything from a root prompt takes about as long to respond. ARP table looks good.

We are not using DNS. nslookup returns: Using /etc/hosts: on hpk210.

All network activity is SLOW, logins and printing (all jetdirect).

Any ideas what is going on.......??? I'm at a loss. I must be missing the boat on this one.

[Patrick Wallek]

Anything in syslog or dmesg that would give a clue? Any stale NFS mounts to your machine from anywhere? Any strange network traffic, other than the delays?

[James A. Donovan]

Check that your NIC's settings are the same as they were before you rebooted.

If you have a sniffer or a program like tcpdump installed, you may be able to get an idea of what's happening at the packet level.

[Rebecca Harding]

syslog looks fine, no error messages, or nothing out of the ordinary.

I checked the NIC card thru SAM, it looks fine.....but what would it look like?

I have never run 'dmesg' before...what is it? and what will it look for?

[Rebecca Harding]

What is ypbind? When I was searching thru the forums and white paper I see that come up ..... what is it?

I see it running on our system, when I grep for it.....maybe I should kill it?

Rebecca

[Patrick Wallek]

Just type dmesg at the prompt. A lot of the info will be what syslog has, but there may be some extra.

Something to check is to make sure the settings on the lan card and the router / switch match. For example make sure they are both at 100 Half Duplex. If you mix duplexes, you can run into problems.

[Bruce Regittko_1]

Hi,

ypbind is a daemon used by NIS clients to connect or "bind" to the NIS server. Instead of killing it, a better bet would be to shut off NIS and see if your problems go away:

/sbin/init.d/nfs.server stop
/sbin/init.d/nfs.client stop

To restart them, reverse the order and use "start" instead of "stop".

Without knowing more about what you are using NIS for, I can't help you troubleshoot. Are you using it for name resolution?

--Bruce

[James A. Donovan]

Typo in Bruce's reply, he meant;

/sbin/init.d/nis.client stop
/sbin/init.d/nis.client stop

[James A. Donovan]

Doh! Typo in my reply!

/sbin/init.d/nis.client stop
/sbin/init.d/nis.server stop

[Kurtkarl]

hi,

I usually encounter same problem as yours whenever I tried to reboot our NIS master or NIS slave server. What I usually do is either
reboot the workstation/server NIS to login or run this command manually from the workstation or server.

/sbin/init.d/nis.client stop
/sbin/init.d/nis.client start

These always solve our problem which I believe same as what you are having now.
Thanks
Joey

[Rebecca Harding]

Can I stop/start the NIS client while users are in and working? Is it safe?

[Kurtkarl]

Yes! it works with me. I usually stop/start NIS client on our workstation while users is currently login.

[Rebecca Harding]

I stopped/started NIS client.

Nothing changed. Still delaying on telnet.....

See the attached output from the start-client

[Rita C Workman]

I don't know that this will clear up your problem. But it is obvious that something has or is continuing to pound your network.
You could try to stop and start inetd and see if this clears it up. Semi drastic measure...
/sbin/init.d/inetd stop
/sbin/init.d/inetd start

But take a look at this thread...as another possible option:

http://forums.itrc.hp.com/cm/QuestionAnswer/1,1150,0xc5ab854994d9d4118fef0090279cd0f9,00.html

Like I said...it's just a thought,
/rcw

[Rebecca Harding]

Exactly how drastic is "Semi Drastic"?

Can I do this during a normal work day with user logged on.....???

[Rita C Workman]

I have....

/rcw

[Rebecca Harding]

Are you sure that is the correct command? The url you pointed me too listed something a little different.

?????

I've got a headache over this!

[Rita C Workman]

Your absolutely right...the correct command should be
/sbin/init.d/inetd -k to stop it
/sbin/init.d/inetd start to start it back up

The thread I pointed you to was just another option to check out...not connected with starting/stopping the net.

/rcw

[Andy Monks · Accepted solution]

Type in the 'domainname' command. It should return nothing (unless your using NIS which from the previous posts I don't think you are).

If it's set, then you'll need to edit the /etc/rc.config.d/namesvrs file and change the line with :-

NIS_DOMAIN=

It will have something after the '='. Delete all characters after the '=' sign.

[Jaimin Parikh]

Hi,

In addition to what everyone had said prior to me, I would suggest to check all your physical level links also.Check for error on server NIC.Check whehter your 'ping' command works with delay or not.

IF all of your network services are running slow I would suggesst to check for following things also.

-If NIC is malfucntioning or generating bad packets network can slow down.
-If port on your central hub is failing or generating bad packets / collisions.
-Try out power cycling your network device to which your service is connected at night.

Good luck.

-Jaimin.

[Rebecca Harding]

Well, it looks like I got it fixed. Oddly enough NIS was running! Why I have no real idea. Went to namesvrs file set NIS_DOMAIN=
to nothing, and stopped the NIS client then tried to restart (of course it would not). Amzingly login is no longer delayed nor is password. !!!!! Don't know the how or why this happened but I'm glad it was fixed. With about 70+ users I was really beginning to worry the NIC was on the way out or a drive was about to go bad! Thank Goodness.
Thanks to ALL!
Rebecca