This document pertains to the NeXTSTEP operating system, which is no longer a supported product of Apple Computer. This information is provided only as a convenience to our customers who have not yet upgraded their systems, and may not apply to OPENSTEP, WebObjects, or any other product of Apple Enterprise Software. Some questions in this Q&A document may not apply to version 3.3 or to any given specific version of NeXTSTEP.
Q: I'm running uucico and all I get is "bus error"--no other messages, even with debugging turned on to any level. What might be wrong?
A: Ensure that the uucico program can access the UUCP spool directory. Since the program is (supposed to be) SetUID uucp and SetGID daemon, this means the uucp user must be able to read and write the directory.
If you examine the files using the UNIX ls(1) command, you should see the following (dates might be different, and the size of the spool directory might be different):
localhost [/me]-7% ls -ldg /usr/lib/uucp/uucico /usr/spool/uucp
---s--s--x 1 uucp daemon 90112 Nov 11 17:25 /usr/lib/uucp/uucico*
drwxr-xr-x 14 uucp daemon 1024 Dec 22 03:30 /usr/spool/uucp/
If you see different results, and you're not absolutely certain why they're different, you can set things right with the following commands:
One other thing to note: the output of the ls on uucico is the same whether the owner and the group have execute permission or not. In UNIX parlance, the mode display in the ls is the same whether the numeric mode is 6001, 6011, or 6111. Be sure it's 6111: SetUID, SetGID, and execute for user, group, and other.
By the way, the rest of the commands in the UUCP suite are likely subject to the same limitations. We have verified that uucp behaves like uucico in this situation; we have not tested the rest of the suite, but anything which needs access to the spool directory are suspect. For completeness, here's another ls -lg:
localhost [/me]-8% ls -lg /usr/bin/uu* /usr/lib/uucp/uu*
---s--s--x 1 uucp daemon 24576 Nov 11 17:25 /usr/bin/uucp*
-rwxr-xr-x 1 uucp daemon 16384 Nov 11 17:26 /usr/bin/uudecode*
-rwxr-xr-x 1 uucp daemon 2984 Nov 11 17:26 /usr/bin/uuencode*
---s--s--x 1 uucp daemon 4620 Nov 11 17:25 /usr/bin/uulog*
---s--s--x 1 uucp daemon 5776 Nov 11 17:25 /usr/bin/uuname*
---s--s--x 1 uucp daemon 24576 Nov 11 17:26 /usr/bin/uupoll*
---s--s--x 1 uucp daemon 8716 Nov 11 17:26 /usr/bin/uuq*
---s--s--x 2 uucp daemon 3548 Nov 11 17:26 /usr/bin/uusend*
---s--s--x 1 uucp daemon 4260 Nov 11 17:26 /usr/bin/uusnap*
---s--s--x 1 uucp daemon 24576 Nov 11 17:25 /usr/bin/uux*
---s--s--x 1 uucp daemon 90112 Nov 11 17:25 /usr/lib/uucp/uucico*
---s--s--x 1 uucp daemon 11136 Nov 11 17:25 /usr/lib/uucp/uuclean*
---s--s--- 1 uucp daemon 32768 Nov 11 17:26 /usr/lib/uucp/uuxqt*
Q: uucico is being uncooperative. Specifically, if someone polls my machine, my machine hangs up the phone (the other side typically sees this after the second
imsg looking for SYNC<
message in the debug output). When I poll that same machine, uucico provides a core dump, after a segmentation fault. What's stranger still is that polling some machines works fine, and those machines can poll mine!
Q:uucico is crashing when it tries to transfer files other than mail. Mail comes through fine, but a file transfer won't. What's wrong?
A: The likely problem is that you have improperly formatted UUCP configuration files. For example, blank lines in your L.sys file can cause the first symptom, and malformed lines in your USERFILE can cause the second.. The UUCP system can't handle these.
In the case of the blank L.sys line, if the line is entirely empty--no spaces, no tabs, just empty--uucico works fine. However, if the line contains only whitespace--spaces and tabs--then uucico crashes. Remove the blank lines, or, if you like white space in your L.sys file, replace the blank lines with otherwise-empty comment lines.
In addition, if expected fields are missing, uucico has been known to crash. For example, the following L.sys entry will crash uucico:
What was desired in this case was to send a newline if the prompt ogin: was not received. What happened instead is that uucico was looking for the next expect string in the expect-send sequence, and it wasn't there. To accomplish this, use the following instead:
... \
"" ATdt555-1212 \
ogin:~20-CR-ogin:-CR-ogin: name \
ssword: YouKnowWhat
In the case of a malformed USERFILE, check for lines with a missing space. The format of USERFILE is
[user],[system] directory
You must have the space between the user,system and the directory. (Yes, user and system are both optional. The comma between them and the space following them are not.)
One other thing which can cause uucico to fail (silently on the remote, with a bus error locally) is if the program--which runs SetUID uucp and SetGID daemon--does not have appropriate access to the UUCP spool directory, /usr/spool/uucp. Ensure that the user uucp can read, write, and search (``execute'') the spool directory. Recommended permissions are 755 (read, write, execute for the user; read, execute for the group; read, execute for others).
Q: uucico is being uncooperative. Specifically, if someone polls my machine, my machine hangs up the phone (the other side typically sees this after the second
imsg looking for SYNC<
message in the debug output). When I poll that same machine, uucico provides a core dump, after a segmentation fault. What's stranger still is that polling some machines works fine, and those machines can poll mine!
Q:uucico is crashing when it tries to transfer files other than mail. Mail comes through fine, but a file transfer won't. What's wrong?
A: The likely problem is that you have improperly formatted UUCP configuration files. For example, blank lines in your L.sys file can cause the first symptom, and malformed lines in your USERFILE can cause the second.. The UUCP system can't handle these.
In the case of the blank L.sys line, if the line is entirely empty--no spaces, no tabs, just empty--uucico works fine. However, if the line contains only whitespace--spaces and tabs--then uucico crashes. Remove the blank lines, or, if you like white space in your L.sys file, replace the blank lines with otherwise-empty comment lines.
In addition, if expected fields are missing, uucico has been known to crash. For example, the following L.sys entry will crash uucico:
What was desired in this case was to send a newline if the prompt ogin: was not received. What happened instead is that uucico was looking for the next expect string in the expect-send sequence, and it wasn't there. To accomplish this, use the following instead:
... \
"" ATdt555-1212 \
ogin:~20-CR-ogin:-CR-ogin: name \
ssword: YouKnowWhat
In the case of a malformed USERFILE, check for lines with a missing space. The format of USERFILE is
[user],[system] directory
You must have the space between the user,system and the directory. (Yes, user and system are both optional. The comma between them and the space following them are not.)
One other thing which can cause uucico to fail (silently on the remote, with a bus error locally) is if the program--which runs SetUID uucp and SetGID daemon--does not have appropriate access to the UUCP spool directory, /usr/spool/uucp. Ensure that the user uucp can read, write, and search (``execute'') the spool directory. Recommended permissions are 755 (read, write, execute for the user; read, execute for the group; read, execute for others).
Q: What are are the various UUCP (uucp, uucico, uux, uuxqt) debug messages, their levels, and the modules from which they are emitted?
A: Following are the debug messages. There are two lists, separated by a line of em-dashes (--); search for an em-dash or for the word Module. (Note that the second list starts about half-way into the file...) The first is the debug messages sorted by level, the second is the messages sorted by module. (The messages are displayed by the UUCP System components when they are given the -x option.)
These lists are based on the Release 2 sources. The Release 1 lists differ only slightly.
Q: I'm sending mail via UUCP. Things work great from my mail server (which is also my UUCP gateway). From a mail client, though, I get error messages indicating the remote UUCP machine is unknown. The bounce message looks like this:
Date: Mon, 13 Apr 92 13:11:11 CDT From: Mailer-Agent (NeXT Mail Agent) Subject: Returned mail: Unable to deliver mail To: amm
----- Transcript of session follows -----
554 rhino!sandy... Never heard of UUCP host rhino
----- Unsent message follows -----
...
What's going on here?
A: One likely source of the problem is that sendmail might not have an uptodate notion of the known UUCP connections. If you've added the remote machine (rhino in the example, above) and neither rebooted the server nor restarted the sendmail process on the server, then sendmail doesn't know about the new connection.
A sendmail daemon process is started when the system boots, by /etc/rc. When sendmail starts up, it runs the command uuname to determine the known UUCP connections. (At least, it does this with all the standard configuration files NeXT ships.) The uuname command is run only once. It is this sendmail daemon that handles all the mail coming from the client machines.
So, why does mail originating locally work? A new sendmail process is run for each locally-originating message; this new sendmail process runs its own instance of uuname when it starts. Since uuname for the new sendmail process has been run after the new system's addition to L.sys, the new sendmail knows about the new system. Q: UUCP is complaining about my mail missing newlines and mail is bouncing. What can I do?
A: If the bounced mail has errors like the example below, the problem can be fixed by editing your UUCP mailer specification in your sendmail.cf.
> From @scapa.cs.ubert.ca:me@uaneuro Thu Jun 6 11:32:04 1991
> Message-Id: <9106061732.AA10617@namao.ucs.ubert.ca>
> Date: Thu, 6 Jun 1991 12:34:01 -0600
> Illegal-Object: Syntax error in From: address found on scapa.cs.ubert.ca:
> From: uaneuro!me (My Account)
> ^-missing newline (LF)
> Illegal-Object: Syntax error in Message-Id: value found on scapa.cs.ubert.ca:
> Message-Id: <9106061834.AA00160@uaneuro>
> ^-missing newline (LF)
> Illegal-Object: Syntax error in To: address found on scapa.cs.ubert.ca:
> To: namao.ucs.ubert.ca!thorjman
> ^-missing newline (LF)
> From: me@uaneuro.uucp
> To: thorjman@namao.ucs.ubert.ca
> Subject: test 2 (non-NeXT)
The fix is to add a new definition of the end of line character to the UUCP mailer definition. Add the text shown in bold to the sendmail.cf file in use on your uucp mail hub machine.
A: You also need to enable uucp in the file /etc/inetd.conf. We ship the system with the line in the file, but commented out:
# Run as user "uucp" if you don't want uucpd's wtmp entries.
# uucp stream tcp nowait root /usr/etc/uucpd uucpd
Just uncomment the `` uucp stream'' line, send inetd a SIGHUP, and you're all set. See the inetd(8) UNIX Manual Page for details on the format of inetd.conf.
By the way, each step accomplished (L.sys and USERFILE being correct on both machines, a uucp entry in /services in NetInfo) is necessary in addition to the modification to inetd.conf.
Note also that in Release 1.0 and Release 1.0a a TCP-based UUCP connection does not work, even if you accomplish everything mentioned in this document. This is because of a bug, fixed in Release 2.