davidy@HWCAE.CFSAT.HONEYWELL.COM (David Young) (01/04/91)
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.comkrowitz@RICHTER.MIT.EDU (David Krowitz) (01/04/91)
Thank you for your detailed correction of the info I passed on regarding SR10.3 TCP/IP problems! Please accept my sincere apologies for passing on some potentially misleading info! I meant to provide pointers to where potential trouble spots might be found and resolved. Apparently you have have been able to check a couple of those spots and to correct my typos! -;) Now, I've gotten the patch for fixing the DN550/560, DN660 display manager, but has anyone gotten a patch for booting their DN330's with the time-of-day problem? == Dave
rees@pisa.ifs.umich.edu (Jim Rees) (01/05/91)
In article <9101040350.AA05473@hwcae.cfsat.honeywell.com>, davidy@HWCAE.CFSAT.HONEYWELL.COM (David Young) writes:
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.
I'm the user who reported this here in comp.sys.apollo. I had wanted to run
without the '-c' switch (which I think is a stupid option), so, not giving
it much thought, I commented out the line that had the '-c' and uncommented
the one that didn't. Unfortunately the one without the '-c' also had output
redirected to /dev/console. This made init hang in the rc file.
I don't remember whether I suggested putting the tcpd in parens, but that's
not what I did. What I did was remove the output redirection. This works
fine.
But I still don't understand why putting the tcpd in parens should cause a
problem. This shouldn't cause the tcpd to run asynchronously. If it does,
something is screwed up.
The whole business of putting echo redirections in parens has always seemed
ugly to me. Why doesn't init just give the console to the shell while it's
running rc, then take it back when it's done?