James writes:

> Note: HP does not support increasing the priority of INETD or any user
>  applications to a priority in the BS queue.
>
>  FYI: Before you assume you are seeing a performance problem with INETD
>  launching services, please make sure you have the General Release FTP
>  and Telnet patches installed as both contain fixes for hangs of INETD.

Let me say that after playing with this for a week, I don't think raising
JINETD to the B queue is as dangerous or as deleterious as James suggests. I
wouldn't have suggested the "fix" if I could have discovered any truly
negative aspects to raising JINETD's priority. And it does completely cure
the logon problem, which can be a serious problem in some circumstances.

James' note addresses several services: Telnet, FTP, SAMBA, BOOTP, and VT. I
can only speak directly about telnet and FTP because those are the only two
that we use on our HP3000s. The others are "black boxes" to me, and that is a
concern that should be taken into account in your considerations.

There are two attributes to a process: its priority and the amount time it is
executed. James addressed the first. JINETD is now a high priority process,
generally in the nature of B149 to B152 (Glance itself runs at B100).
Nonetheless, when JINETD is moved to the B queue, its system utilization
remains so small that it falls below Glance's threshold and doesn't appear on
the list of executing processes. 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. Indeed, that is
exactly the kind of process you want to put into the B queue: very high
piority, very short, in-and-out processes.

The only exception I've found to that statement is every once and a while
during an FTP logoff a process named "TCPSIP" uses ~1.1% of CPU at the B149
level to do some sort of housecleaning. Otherwise, telnet logons and logoffs
never seem to gather sufficient resource utilizations to break Glance's
reporting threshold (0.1%?).

These CPU utilization rates for JINETD appear to be the same whether JINETD
is being run out of the C or B queue.


James and Donna write:

> > I would suggest you pursue an enhancement request for INETD to increase
>  > the functionality to support running INETD as a system process and
>  > create the service processes at the appropriate user priority levels.
>  > I have recommended this solution in the past SR 4701-371708 but I was
>  > disappointed with the final ";PRI=CS" solution.  I would suggest a new
>  > SR - Enhancement Request be submitted and of course talk up this need
>  > at HP-World.

>  Pass a priority to services launched by INETD via a parameter rather than
>  allowing simple inheritance from the priority of the root INETD process.
>  (votes: 36)

I'm not sure if I understand this or not, but this may already be corrected.
We tend to run the latest telnet patches and I have no machine that's not on
the latest patch,  so we may not be a good test for the above comment.
Nonetheless, we've been running JINETD in the B queue for about a week now.
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.

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.

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.


Finally, Mark writes concerning the increased danger of a denial-of-service
attack with JINETD in the B queue:

> It would be easy for a hacker to bring your system to its knees by writing a
>  program that did a tight loop connecting and disconnecting to the various
>  services in /etc/inetd.conf (assuming your firewall didn't block these
> attempts in the first place).

I can't really address or refute this argument one way or the other, other
than to say that there is real value in a low-bandwidth connection to the
world :-). You only get so many attempts per second under a DOS attack, and
that rate is determined wholly by your bandwidth.

However, as in all hypotheticals, you have to make some guess as the
probability that such a DOS attack would ever be made against you (and if it
were, what did you do to make them so mad?) Given all of the plus and minuses
of a realistic cost/benefit analysis, I would have to think that this must
rank fairly close to the bottom.

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.

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.

I would not recommend raising JINETD to the B queue if you have any
reservations at all about doing so. All that I can say for certain is that
after a week's worth of use here -- and further substantial and extensive
testing today -- I can find no deleterious effects of doing so on our several
machines.

Wirt Atmar