Hello Wirt, Folks @ 3000-l,
Re: Telnet logon difficulties
My notes in response to "Telnet logon difficulties".
The SR I was thinking about when I recommended the GR patches is:
SR: 8606108146
FROM: PTDFDN5
Fix to avoid Telnet and FTP hangs out of PTID_INIT
A quick search on the HP ITRC and I found SR 8606108146 fixed in:
------------------------------------------------------------------------
These fixes are available in the following patch revisions and later:
Module 5.0-push 5.5 6.0 6.5 ?
( ) (PTDFDK0) (PTDFDK2) (PTDFDN5) ( )
---------------- --------- --------- --------- --------- ---------
? ? ? ? ? ?
------------------------------------------------------------------------
FYI: The current (8/15/00) 5.5, 6.0 & 6.5 patches for FTP and Telnet
are and this fix is included in the GR patches for 5.5, 6.0 & 6.5.
FTPFDP2 (A) GR 6.5 PTDFDN5 (A) GR 6.5
FTPFDH3 (A) GR 6.0 PTDFDQ6 (A) GR 6.0
FTPFD90 (A) GR 5.5 PTDFDQ5 (A) GR 5.5
My feed back concerning INETD in the BS queue is: Few problems have been
seen with INETD and I feel it would be a safe and a good implementation
for CSY Labs to 1) eliminate the JINETD job, 2) introduce INETD
as a system process, 3) assign INETD to the BS queue at B149 which
is the same priority as many of the other network system processes.
4) implement in INETD support for control of services started by
INETD to be launched in the CS, DS or ES queues.
I will await a customer to submit a SR for this request and I will
include all necessary documentation to that SR and forward it to the
CSY labs with my recommendation.
As far as the recommendation to do an ALTPROC on JINETD again my answer
is JUST SAY NO. I say this from a self-preservation perspective since
in the end after a memory dump of an abort or a hang in network code
is detected and the System Interrupt Team (SIT) in the RC looks into
the problem and the MPE Network Team (MPENET) in the RC investigates
and reviews a problem from a network perspective, then a SR is submitted
and I get a call //;~0
My concern is really not with INETD being promoted to B152, as I said
above I would recommend B149. I do have serious concerns with INETD being
promoted to B100 above all of the other network process at B149, an
example is TCPSIP is at B149. If TCPSIP does not get the resources to
run you are not going to get a socket connection established. This is
very similar to attempting to perform a FWRITE at a higher priority than
the I/O subsystem.
My real concern is the services configured in INETDCNF (except HP
proprietary telnet solution) which are now going to be running at a B152
(above all user processes) or B100 priority (above all network and many
system processes). First I am concerned about the existing services:
'echo, daytime, time, discard, chargen, bootps, tftp, nmbp, smbp and ftp'.
If any of these are started they will execute at the B152 or B100 and
they will impact the performance of user applications in the CS queue
until they are terminated. Of this list my greatest concern would be FTP
which I almost would prefer to have launched in the DQ due to it's batch
like characteristics, now would run as a server in the B152 or B100 queue
impacting online user performance or impacting network and system process
performance respectively. Keep in mind it is possible and not uncommon
that multiple inbound FTPSRVR request could be executing at the same time.
A secondary concern is I am not certain how many folks have implemented
their own services configured in INETDCNF which are created by INETD, but
suppose I have a sockets based application that is created under INETD
and this application receives a data record, opens 10 data bases, computes
and writes to the data bases, closes the data bases and then terminates
the service... This by the way is a really kewl implementation of receipt
of bar code data from the factory shipping/receiving department. Needless
to say we would want this operation to be running at the bottom of the
CQ "DECAY" and would not want it running at the top of the CQ B152 where
it was slowing down online transactions and we certainly would not want
it running at B100 where it would likely prevent new users from getting a
":" prompt.
Bottom line is moving INETD into the BS queue is a solution which needs
to be architected by CSY Labs and ;altproc ;pri=BS is not an appropriate
or HP supported solution.
My suggestion is if you are going to mess with the ";altproc ;pri=BS"
that you or someone on your staff have the ability to read a memory dump
and if you find a process launched by INETD is involved avoid the call
to our friends at the HP-RC.
As far as feed back to having performed rigorous testing with ";altproc
;pri=BS" in your environment... I don't disagree that this implementation
works in your environment... I frequently attempt to duplicate aborts,
hangs and other problems in my environment as does the HP RC and the most
common result you will hear is "hmmm... I don't see that problem on my
test systems...". I know that anyone who has called the HP RC has heard
this one.
Feed back on "Duration-of-execution is at least as important as priority.
If a process is very rarely executed, and its execution times are very
short,
B queue residency is no sin". One thing to keep in mind is execution in the
B queue is very much like locking data bases or semaphores... you must know
the system designed strategy and in the example of locking data bases you
must
know the locking order or else the deadly embrace. In the case of process
priorities you must know the architeched process priority hierarchy and as
in
my example of FWRITE above you must avoid the condition where the FWRITE is
performed at a higher priority than the I/O subsystem... and in this example
you must avoid the condition where a network i/o is performed at a higher
priority than the TCP code processing the network i/o. You must also take
into consider customer/user performance expectations and running a FTP file
transfer at a higher priority than a online transaction entry is in general
not considered appropriate "on the HP e3000 anyway".
Quick answers to your other questions.
>When I launch a 3000-to-3000 FTP command in the C queue on 6.5, the FTP
>process is run in the C queue (the originating queue), not the root (B
>queue). Indeed, other than at FTP's launch or closure, do you ever get the
>slightest hint that JINETD is in the B. The same is exactly true when I
>launch FTP as a job. The processes are solidly in the D queue (D202),
exactly
>where I would expect them to be.
Yes, this is true on the "source" system, but not true on the server system
where INETD and any created servers are running at the ALTPROC ;PRI=BS
priority of B152 or B100 as we saw in the "showproc ;pin=1;system;tree".
>Because we run our HP3000s with non-overlapping queues, it's easy to
>demonstrate that the B-queue JINETD launched FTP process is truly in the D.
>When I run a 100% CPU C-queue process, FTP is completely starved of
>resources. Nothing moves on the LAN for as long as the 100% C-level CPU
>process is running.
We have already demonstrated in the "showproc" commands in the first message
of this thread that the INETD launched FTPSRVR is launched at the BS
priority
inherited from the father INETD process.
>Similarly, telnet sessions appear in the queue in which they're launched --
>but with the exception that telnet session establishment, whether it's in
the
>B or C queue, is such a low resource process that it seems invisible to
>Glance. Essentially all of the CPU resource loading is consumed by the CI
>session establishment processes that appear common to all modes of
>communication.
Telnet is a HP proprietary server and launches itself in the correct queue
priorities. Telnet is not a problem with "ALTPROC ;PRI=BS", but all of the
other services launched by INETD are.
>Under any circumstance, I wholly agree with James' original statement that
no
>user processes should be put into the B queue. That queue should be
reserved
>for processes of extremely short duration that are of very high priority,
>basically akin to the ticking of a clock. JINETD actually seems to operate
in
>that manner.
Yes, I agree that INETD is a good candidate to be put into the B QUEUE and I
would suggest B149. I have a "serious" problem with the fact that the
server
processes created by INETD will inherit the same priority as INETD.
>I also want to emphasize that I consider moving JINETD to the B queue to be
a
>temporary workaround. There's some sort of a simple bug somewhere in the
>telnet process initiation code -- and I'm sure that when it's found, it
will
>be obvious and very easy to correct. However, it may be some time before
the
>correction reaches the people who are currently experiencing difficulty in
>user logons.
This is not a workaround I would recommend for a production environment and
not a workaround recommended by HP. In a controlled test environment HP
division support (ouch, I think that is me) may recommend ;PRI=152 be
specified in the JINETD job ":run jinetd.net.sys" command as a trouble
shooting step, but this is a trouble shooting tool and not a solution to a
problem and not a solution left executing in a production environment.
Bottom Line:
------------
I buy into the fact that WIRT has seen a problem in certain environments
where INETD is starved and this prevents or delays Telnet logons. I have
attempted to duplicate this problem on my systems and sorry, here comes
the standard reply "hmmm... I don't see that problem on my test systems...".
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.
I would recommend a SR be submitted requesting the priority of INETD be
raised to avoid possible starvation and that a PRIORITY QUEUE option be
added to INETDCNF for each service including customer/user code (else
default is CS).
Regards,
James Hofmeister
Hewlett Packard
Worldwide Technology Network Expert Center
P.S. My Ideals are my own, not necessarily my employers.
|
