Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!ucsd!ucbvax!HWCAE.CFSAT.HONEYWELL.COM!davidy
From: davidy@HWCAE.CFSAT.HONEYWELL.COM (David Young)
Newsgroups: comp.sys.apollo
Subject: Starting tcpd in rc.local
Message-ID: <9101040350.AA05473@hwcae.cfsat.honeywell.com>
Date: 4 Jan 91 03:50:53 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 92

I just read the January 1991 issue of "Workstation HP/Apollo" (Volume 7, Number 1).
An article starting on page 22 entitled "SR10.3: What's new, what's not" by David
Krowitz states:

    "Another user reported stumbling over a minor typo in the /etc/rc.local file
    that can cause the "init" process to hange while processing the file.  The 
    line that starts the TCP/IP daemon is not enclosed in the parentheses needed
    to start in a subshell -- i.e. that the line should be:

        (/etc/tcpd >/dev/console)

    rather than:

        /etc/tcpd >/dev/console

    Apparently the latter can cause "init" to wait indefinitely if "tcpd" can not 
    get access to the console for any reason."


DO NOT DO THIS!  I read the article, applied the *fix* (my node only) and forgot 
about the whole incident.  The change I made was:

       /etc/tcpd  -c

to be:

       (/etc/tcpd  -c >/dev/console)

Later that same day I rebooted my node because I was having obscure problems
with my node, and seemed like it needed a reboot to fix. Fine I rebooted. 
That's when the problems started.  X11 *still* didn't work.  I finally traced it
back to the parentheses around the /etc/tcpd command in the /etc/rc.local file.

If you read the header in the /etc/rc file:
 
    "echo commands are parenthesized so that they will be run
    in a subprocess (echo is builtin to the shell).  Otherwise,
    the shell running this script (and all the programs started
    from it) would acquire /dev/console as their controlling tty."

If you look at the /etc/rc.local file from Apollo in the AA, the rc.local file
looks like this (SR10.3):

    if [ -f /etc/tcpd -a -f /etc/daemons/tcpd ]; then
    	(echo " tcpd\c" >/dev/console)
    #	/etc/tcpd >/dev/console
    	/etc/tcpd -c 
    fi

Looks like someone from Apollo found and fixed (but neglected to remove) a
potential problem.  As long as you *don't* redirect to /dev/console, everything
is fine.   What happens when you DO put /etc/tcpd in parentheses?  TCPD is
spawned into a sub-process and finishes ASYNCHRONOUS with respect to the
/etc/rc.local script. This means (in my case), the /etc/ifconfig was executed
*before* tcpd was  initialized and ready to be configured.  Since TCPD wasn't up
(and configured) timed, Xapollo, and inetd all failed to work!

So get *rid* of the parentheses and the commented out line:

    #	/etc/tcpd >/dev/console

Or you will have problems...


I'd also like to mention another matter that is not Dave's fault; but I knew 
would be misconstrued when originally posted by my colleage.  Dave also mentions
in the *next* paragraph:

    "Yet another user has reported he was unable to get either "telnet" or "ftp"
    to transfer more than roughly 128 bytes before he got disconnected with the
    message "connection closed by foreign host.  [...]  At any rate, he found
    that starting the TCP/IP daemon with the -p0 option fixed the problem."

TCP/IP at SR10.3 works fine.  (It is even tolerant to broadcast storms on
our ethernet (SR10.1 TCP freezes, and a reboot is usually necessary)).  When we
were having problems connecting to a remote host, the remote host was another
Apollo on the other end of a *very* busy 56kps dedicated line to our corporate
headquarters.  Since pinging could *not* reliably be received within the default
4 second interval (this line *freezes* for up to 10 seconds or more at a time),
the connection would be dropped.  It was TCP/IP sessions made to this *one*
location that caused the problem, and the -p0 option fixed the problem.  SR10.1
TCPD did not seem to as sensitive to this delay, whereas SR10.3 does.  

All I really wanted to do was illustrate that if the information is taken out
its context, a very bad connotation can be associated with an incident that
*really* is *not* a problem. 
         

David J. Young                      Honeywell -- Air Transport Systems Division
Phone: 602.436.1311                   P.O. Box 21111 M/S P26D3 Phoenix AZ 85036
FAX:   602.436.1310                          INET: @cim-vax.honeywell.com:
UUCP: uunet!asuvax!apciphx!hwcae!davidy        davidy@hwcae.cfsat.honeywell.com