sendmail on SCO ODT + uucp

[Steve Hole]

In the orginal article Scott Simpers writes:
> We are having a peculiar problem with sendmail, and I would
> appreciate any ideas, suggestions, or solutions.
> 
> Sendmail is running on an SCO ODT 1.0 system, which is our UUCP
> gateway.  The problem appears sending UUCP mail from other hosts on
> our Lan to UUCP sites.  It works fine delivering, via SMTP, to all
> our local machines, and sometimes works OK when sending, via UUCP,
> to other hosts.
> 
> The probem is that it will someimes get into a state where it says
> "Cannot exec '/usr/bin/uux' errno=13".  This doesn't seem to be a
> problem when sending UUCP mail from the local (ODT) system, but
> rather when another systemon our networkis attempting to get it to
> send UUCP mail.  Once it gets into this state where it will only
> send local UUCP mail, the only solution appears to be to kill and
> restart sendmail.
> 

OK, Scott, you are not going crazy.  I have noticed the identical
problem, except that I am running smail v3.19.   First of all let me
refine the occurrence of the problem a little.  The problem occurs on
our machine under the following conditions:

1.  If I start sendmail from the rc as a an stmp daemon with the
    following arguments:

    /usr/lib/sendmail -bd -q1h

    the any messages recieved via SMTP and routed to an external
    connection via uucp will fail with a similar error message to the
    one you show above.  If I kill the daemon started by the rc, and run
    it from the command line, everything works fine.

2.  If I start smtpd via inetd.conf, it fails similarly every time.

Therefore, it would seem that smtp daemon processes started without a
controlling terminal cannot execute uux.  I have absolutely no idea why.
Perhaps something in the environment of a process started from a shell
command line is required and not present when started from either the rc
or inetd.

For the longest time, I thought that it was some subtle bug in smail
that was causing the problem, but I no longer think so.  The reason for
the change is that I have noticed several other intermitent problems
with the SCO Unix (both v3.2 and v3.2.2) uucp distribution.  Here are
some of the problems that I see regularly occurring on the SCO Unix
machines we maintain.

Please note that all of these machines we are using either
/usr/lib/uucp/dialTBIT or /usr/lib/uucp/dialHA24 as the dialer.  The
serial ports are standard UARTS that come with the machine (not a smart
card). 

1.  When ever cu or uucico dial out over a serial port that is running
    /usr/lib/uugetty on it, as soon as uucico or cu acquire the port, the
    open succeeds for uugetty as well!   Doing a ps -e shows that both
    uugetty and the dialer have acquired the port, and they proceed
    to fight for the data on the port.  This causes the uucico or the cu
    to fail regularly.

3.  The Sysfiles file does not function.  If you try to use it, uuname,
    cu and uucp refuse to recognize that the system names exist.  Uucico
    does recognize the name though, as you can slam a poll to the sites
    named through the Sysfile.  The equivalent configurations worked
    perfectly under Xenix.

So I went looking around, and to my surprise, I found that every single
binary in the uucp distribution is a Xenix binary (Microsoft a.out
separate pure segmented word-swapped 386 executable).

Now I put on my theory hat.  I have had problems in the past with
executables compiled as Xenix binaries when running on SCO Unix.  GNU
emacs is a good example.  While it worked fine most of the time, it
would occaisonally lock up, and often couldn't stat some of the
directories (especially NFS mounted directories).  When I recompiled it
as a COFF binary, everything worked hunky dorry.

So I begin to wonder if there are some subtle incompatibilities that
show up here between Xenix binaries and the Unix kernel.  SCO is
probably going to barf all over me for this, but I have checked the code
that I have, and I can see no reason why smail or emacs should have
behaved in the manner that they did.  Not having the source for the uucp
stuff, I can offer no opinion about it (other than the implied one :-).

-- 

-- 
Steve Hole  		         mail: steve at edm.isac.ca
ISA Corp.			 uucp: !{uunet, alberta}!ncc!isagate!steve
Edmonton, Alberta, Canada       phone: (403) 441-4121