/bin/sh might not work for complex commands with background processes

[terryl at tekcrl.UUCP]

     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."