flon@pollux.usc.edu (03/26/91)
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. The permission on /usr/in/uux are: ---s--x--x 1 uucp uucp 63408 Dec 09 1989 /usr/bin/uux so it should be runnable by anyone. I have run out of ideas. Please reply via email, and I'll summarize for the net if anything useful surfacs. Thanks. Scott Simpers Quality Software Products voice: (213)410-0303 5711 W Slauson Avenue Suite 240 fax: (213)410-0124 Culver City, CA 90230 ...uunet!qsp!scotts --
steve@edm.isac.CA (Steve Hole) (03/30/91)
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@edm.isac.ca ISA Corp. uucp: !{uunet, alberta}!ncc!isagate!steve Edmonton, Alberta, Canada phone: (403) 441-4121
rickert@mp.cs.niu.edu (Neil Rickert) (03/30/91)
In article <1991Mar29.175919.17154@edm.isac.CA> steve@edm.isac.ca (Steve Hole) writes: > >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. This is a wierd problem. I don't know if this will work, but here is a possible stopgap workaround. 1. Run sendmail from /etc/rc with only the -bd operand. 2. Modify the definition of the UUCP mailer, by making it an "expensive" mailer. (Check your manual for mailer flags). You should be able to get it to queue all UUCP mail, instead of sending directly to uux. 3. Run a script regularly from 'cron' to clear out the queue. The script should try to attach itself to a tty, perhaps by redirecting stdin and stdout to the console. Then it can invoke sendmail with the -q option. As I said, I am not sure whether it will solve your problem, but it may be worth a try. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
rk@theep.boston.ma.us (Robert A. Kukura) (04/01/91)
In article <1991Mar29.175919.17154@edm.isac.CA> steve@edm.isac.CA (Steve Hole) writes: 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. > Most likely, if this is the problem I've seen before, incoming SMTP mail is not being reliably delivered either. 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. Its not the controlling terminal or the environment, its SCO's infamous security feature, the LUID, or login user id. The init process that runs the rc scripts does not have one, and therefore the sendmail daemon started from the rc script does not have one either. This means that the kernel prevents the sendmail daemon from execing /usr/bin/uux, which I believe (I'm not on an SCO system at the moment), has the SUID bit set. When a user sends mail, the sendmail that is invoked has the user's LUID, so it is permitted to exec /usr/bin/uux, and delivery succeeds. When mail arrives via SMTP for forwarding, its handled by the sendmail daemon with no LUID and it fails. If you kill and restart the sendmail daemon by hand, it has your LUID, and succeeds. The solution is to give the sendmail daemon started by init an LUID by editing /etc/rc2.d/S85tcp to read something like: /bin/su root -c "/usr/lib/sendmail -bd -q1h" I hope this helps. -- -Bob Kukura internet: rk@theep.boston.ma.us uucp: spdcc!theep!rk