terryl@tekcrl.UUCP () (08/28/85)
I ran across a peculiar problem the other day that took a day and a half
to track down. All of a sudden, /etc/rlogind would not get started up by
/etc/rc when the system was rebooted. Below is an excerpt of our /etc/rc:
(
/etc/cron;
/etc/doroutes
if [ -f /etc/arp.hosts ];
then
/etc/arp -f /etc/arp.hosts &
fi
if [ -f /etc/ftpd ];
then
/etc/ftpd &
fi
if [ -f /etc/rlogind ];
then
/etc/rlogind &
fi
if [ -f /etc/telnetd ];
then
/etc/telnetd &
fi
if [ -f /etc/rexecd ];
then
/etc/rexecd &
fi
.......
) &
Through some simple experimentation by moving around the startups of
daemons in our rc, I tracked it down to the second daemon getting started
after the /etc/arp command. What had happened is that a bogus entry in
/etc/arp.hosts was causing /etc/arp to exit with a non-zero exit status.
A little more debugging with a special version of test ( [ in the above
examples) showed that test was indeed returning a real zero exit status,
but /etc/rlogind did not show up in a ps. With a little more debugging
I found out that /etc/arp was returning a non-zero exit status right after
test returned a zero exit status, and it was the non-zero exit status of
/etc/arp that was used to determine if /etc/rlogind should be run or not.
I do believe that this is a bona-fide /bin/sh bug, but I really don't want
to track it down (I cry every time I have to look at the sources....(-: ).
Also note that all of the daemons are started up in a parenthesized list
that is run in the background, so I don't know if this has anything to do
with it. Comments, anyone???? Bug fixes, anyone?????
Terry Laskodi
of
Tektronix
"There is no conflict between capitalism and spiritualism."