Hello Wirt, folks @ 3000-l,
Re: Telnet logon difficulties
I tested a bunch and finally came up with a scenario where this problem
can be duplicated. I was hoping I could get a customer to open the SR,
but I went ahead and opened one under HP. It will probably not be
searchable in HP ITRC since it is a HP Internal SR.
Here is the problem description from the SR 8606156115 text:
----------------------------------------------------------------------
08/16/00 James Hofmeister (WW Tech Expert Center - Atlanta) tn 7956426,
INETD 6.5, decays to bottom of C queue logons intermittently fail.
This problem was initially described in SR 4701-371708. This SR
describes insufficient priority queue for INETD results in logon
attempts which do not reach the ":" prompt. The workaround to this
problem was to specify ";PRI=CS" on the run command in the JINETD job.
This solved a large percent of the problems seen, but still
intermittent cases of failing to get a ":" prompt are seen on busy
systems.
Note: in this sample after several successful connections have been
established, INETD decays to the bottom of the CQ.
B152 0:00.435 WAIT J4 44 (JSMAIN.PUB.SYS)
D202 0:00.391 WAIT J4 63 :RUN inetd.net.sys;PRI=CS
C200 0:02.198 WAIT J4 70 (INETD.NET.SYS)
In this situation if a system has many new process's being introduced
at the top of the CQ gradually decaying or many new process's which are
of a short duration (i.e. don't decay all of the way to the bottom of
the CQ before terminating), it is possible to drive the condition where
INETD intermittently does not respond in sufficient time before network
timers close the connection. From the customer perspective a ":"
prompt is never displayed upon attempting to telnet to a system.
----------------------------------------------------------------------
I also did a test of Wirt's finding of ":altproc job=#j5;pri=bs"
followed by ":altproc job=#j5;pri=cs" and I verified this only defers
the problem... When the second altproc is performed this places INETD
at the top of the C queue 152, but not for long, after a few telnet
logons it once again has migrated to the bottom of the C queue 200 and
the problem can be duplicated again in the correct environment as
described in the SR 8606156115 problem text.
I will let you know how progress goes on SR 8606156115.
Regards,
James Hofmeister
Hewlett Packard
Worldwide Technology Network Expert Center
P.S. My Ideals are my own, not necessarily my employers.
James, Jeff,
> I did the basic >10 goto 10 >run and had no problems logging on telnet
> sessions on both my 6.5 967 and my 6.0 917LX. If you have further
> details of how this problem can be duplicated I will be happy to help.
In furtherance of the hypothesis that whatever is the matter with INETD when
it is run in the C queue such that it suppresses all login attempts on a
very
busy machine appears to be a simple problem, let me explain an experiment I
ran several times tonight, on both a 5.5 PP7 918 and a 6.5 918. Moreover, it
may also explain your results above.
This evening, I recreated a mysterious event that occurred when Jeff and I
were playing with this problem about a week ago: the logon problem simply
went away when we were attempting to first demonstrate it. I had to knock
the
918 down and reboot the machine to get the problem back.
I now know how to recreate this event reliably: On a freshly booted machine,
with INETD runnning in the C queue, logon using telnet, bring up BASIC and
run a program no more complicated than your "10 goto 10" program. Now
attempt
to logon again, using a new instance of a terminal emulator. CPU utilization
will be 100% and logons should now prove to be impossible.
Now raise the priority of INETD by typing:
:altproc job=#j5;pri=bs
New logons are now instantaneous, as I mentioned before. But now for the
kicker. If you now reverse the process and type:
:altproc job=#j5;pri=cs
and move INETD back to the C queue, all the while having the BASIC program
consume 100% of the CPU, voila, for some reason (probably one of an
unitialized variable, as Jeff earlier suspected), telnet logons now remain
as
immediate and as quick as they are when INETD was run in the B queue.
When I do this, all indications that I can measure indicate that INETD is
truly back in the C queue (or at least equal to the way that it started
out).
Nonetheless, the logon problem is now "cured."
Thanks much for your efforts. If I can be of any further help, please don't
hesitate to ask.
Wirt
|
