uux will automatically start up
uucico to call another system whenever work is queued up.
However, the call may fail, or you may have put in time restrictions
which prevent the call at that time (perhaps because telephone rates are
high) (see section When to Call). Also, a remote system may have work
queued up for your system, but may not be calling you for some reason
(perhaps you have agreed that your system should always place the call).
To make sure that work gets transferred between the systems withing a
reasonable time period, you should arrange to periodically invoke
These periodic invocations are normally triggered by entries in the `crontab' file. The exact format of `crontab' files, and how new entries are added, varies from system to system; check your local documentation (try `man cron').
To attempt to call all systems with outstanding work, use the command `uucico -r1'. To attempt to call a particular system, use the command `uucico -s system'. To attempt to call a particular system, but only if there is work for it, use the command `uucico -C -s system'. (see section Invoking uucico).
A common case is to want to try to call a system at a certain time, with periodic retries if the call fails. A simple way to do this is to create an empty UUCP command file, known as a poll file. If a poll file exists for a system, then `uucico -r1' will place a call to it. If the call succeeds, the poll file will be deleted.
A poll file can be easily created using the `uux' command, by requesting the execution of an empty command. To create a poll file for system, just do something like this:
uux -r system!The `-r' tells `uux' to not start up `uucico' immediately. Of course, if you do want `uucico' to start up right away, omit the `-r'; if the call fails, the poll file will be left around to cause a later call.
For example, I use the following crontab entries locally:
45 * * * * /bin/echo /usr/lib/uucp/uucico -r1 | /bin/su uucpa 40 4,10,15 * * * /usr/bin/uux -r uunet!
Every hour, at 45 minutes past, this will check if there is any work to
be done, and, if there is, will call the appropriate system. Also, at
4:40am, 10:40am, and 3:40pm, this will create a poll file file for
`uunet', forcing the next run of
uucico to call
To accept calls from another system, you must arrange matters such that
when that system calls in, it automatically invokes
The most common arrangement is to create a special user name and
password for incoming UUCP calls. This user name typically uses the
same user ID as the regular
uucp user (Unix permits several user
names to share the same user ID). The shell for this user name should
be set to
Here is a sample `/etc/passwd' line to accept calls from a remote system named airs:
Uairs:password:4:8:airs UUCP:/usr/spool/uucp:/usr/lib/uucp/uucicoThe details may vary on your system. You must use reasonable user and group ID's. You must use the correct file name for
uucico. The password must appear in the UUCP configuration files on the remote system, but will otherwise never be seen or typed by a human.
uucico appears as the login shell, and that it will be
run with no arguments. This means that it will start in slave mode and
accept an incoming connection. See section Invoking uucico.
On some systems, creating an empty file named `.hushlogin' in the
home directory will skip the printing of various bits of information
when the remote
uucico logs in, speeding up the UUCP connection
For the greatest security, each system which calls in should use a
different user name, each with a different password, and the
called-login command should be used in the `sys' file to
ensure that the correct login name is used. See section Accepting a Call,
and see section Security.
If you never need to dial out from your system, but only accept incoming
calls, you can arrange for
uucico to handle logins itself,
completely controlling the port, by using the `--endless' option.
See section Invoking uucico.
Taylor UUCP does not include a mail package. All Unix systems come with
some sort of mail delivery agent, typically
MMDF. Source code is available for some alternative mail
delivery agents, such as
IDA sendmail and
Taylor UUCP also does not include a news package. The two major Unix
news packages are
INN. Both are available in
source code form.
Configuring and using mail delivery agents is a notoriously complex topic, and I will not be discussing it here. Configuring news systems is usually simpler, but I will not be discussing that either. I will merely describe the interactions between the mail and news systems and UUCP.
A mail or news system interacts with UUCP in two ways: sending and receiving.
When mail is to be sent from your machine to another machine via UUCP,
the mail delivery agent will invoke
uux. It will generally run a
command such as `uux - system!rmail address', where
system is the remote system to which the mail is being sent. It
may pass other options to
uux, such as `-r' or `-g'
(see section Invoking uux).
The news system also invokes
uux in order to transfer articles to
another system. The only difference is that news will use
rnews on the remote system, rather than
You should arrange for your mail and news systems to invoke the Taylor
UUCP version of
uux. If you only have Taylor UUCP, or if you
simply replace any existing version of
uux with the Taylor UUCP
version, this will probably happen automatically. However, if you have
two UUCP packages installed on your system, you will probably have to
modify the mail and news configuration files in some way.
Actually, if both the system UUCP and Taylor UUCP are using the same
spool directory format, the system
uux will probably work fine
with the Taylor
uucico (the reverse is not the case: the Taylor
uux requires the Taylor
uucico). However, data transfer
will be somewhat more efficient if the Taylor
uux is used.
To receive mail, all that is necessary is for UUCP to invoke
rmail. Any mail delivery agent will provide an appropriate
rmail; you must simply make sure that it is in the
command path used by UUCP (it almost certainly already is). The default
command path is set in `policy.h', and it may be overridden for a
particular system by the
(see section Miscellaneous sys File Commands).
Similarly, for news UUCP must be able to invoke
rnews. Any news
system will provide a version of
rnews, and you must ensure that
is in a directory on the path that UUCP will search.
In general, the layout of the spool directory may be safely ignored.
However, it is documented here for the curious. This description only
SPOOLDIR_TAYLOR layout. The ways in which the other
spool directory layouts differ are described in the source file
Directories and files are only created when they are needed, so a typical system will not have all of the entries described here.
rnews, send an `E' command rather than an execution file (see section The E Command).
uucicowill create an execution file on the fly when it receives an `E' command.
uustat --statusbasically just formats and prints the contents of the status files (see section uustat Examples). Each status file has a single text line with six fields.
uucicowas unable to open the port.
uucicois currently talking to the system.
uucicomay attempt another call. This is set based on the retry time; see section When to Call. The `-f' or `-S' options to
uucicodirect it to ignore this wait time; see section Invoking uucico.
uuxqtexecutes a job requested by
uux, it first changes the working directory to the `.Xqtdir' subdirectory. This permits the job to create any sort of temporary file without worrying about overwriting other files in the spool directory. Any files left in the `.Xqtdir' subdirectory are removed after each execution is complete.
uuxqtare executing simultaneously, each one executes jobs in a separate directory. The first uses `.Xqtdir', the second uses `.Xqtdir0001', the third uses `.Xqtdir0002', and so forth.
uuxqtencounters an execution file which it is unable to parse, it saves it in the `.Corrupt' directory, and sends mail about it to the UUCP administrator.
uuxqtexecutes a job, and the job fails, and there is enough disk space to hold the command file and all the data files, then
uuxqtsaves the files in the `.Failed' directory, and sends mail about it to the UUCP administrator.
sequencecommand is used for a system (see section Miscellaneous sys File Commands). The sequence number for the system system is stored in the file `.Sequence/system'. It is simply stored as a printable number.
uucicoreceives the file into `.Temp/system/temp', where system is the name of the remote system, and temp is the temporary file name. If a conversation fails during a file transfer, these files are used to automatically restart the file transfer from the point of failure. If the `S' or `E' command does not include a temporary file name, automatic restart is not possible. In this case, the files are received into a randomly named file in the `.Temp' directory itself.
uucicowill store the data file in the `.Preserve' directory, and send mail to the requestor describing the failure and naming the saved file.
uucicoacknowledges receipt of a file, it is possible for the acknowledgement to be lost. If this happens, the remote system will resend the file. If the file were an execution request, and
uucicodid not keep track of which files it had already received, this could lead to the execution being performed twice. To avoid this problem, when a conversation fails,
uucicorecords each file that has been received, but for which the remote system may not have received the acknowledgement. It records this information by creating an empty file with the name `.Received/system/temp', where system is the name of the remote system, and temp is the temp field of the `S' or `E' command from the remote system (see section The S Command). Then, if the remote system offers the file again in the next conversation,
uucicorefuses the send request and deletes the record in the `.Received' directory. This approach only works for file sends which use a temporary file name, but this is true of all execution requests.
Lock files for devices and systems are stored in the lock directory,
which may or may not be the same as the spool directory. The lock
directory is set at compilation time by
`policy.h', which may be overridden by the
in the `config' file (see section Miscellaneous config File Commands).
For a description of the names used for device lock files, and the format of the contents of a lock file, see section UUCP Lock Files.
uucicowhile talking to a remote system, and are used to prevent multiple simultaneous conversations with a system. On systems which limit file names to 14 characters, only the first eight characters of the system name are used in the lock file name. This requires that the names of each directly connected remote system be unique in the first eight characters.
uuxqtstarts up, it uses lock files to determine how many other
uuxqtdaemons are currently running. It first tries to lock `LCK.XQT.0', then `LCK.XQT.1', and so forth. This is used to implement the
max-uuxqtscommand (see section Miscellaneous config File Commands). It is also used to parcel out the `.Xqtdir' subdirectories (see section Execution Subdirectories).
uuxqtis invoked with the `-c' or `--command' option (see section Invoking uuxqt), it creates a lock file named after the command it is executing. For example, `uuxqt -c rmail' will create the lock file `LXQ.rmail'. This prevents other
uuxqtdaemons from executing jobs of the specified type.
uuxqtis executing a particular job, it creates a lock file with the same name as the `X.' file describing the job, but replacing the initial `X' with `L'. This ensures that if multiple
uuxqtdaemons are running, they do not simultaneously execute the same job.
The spool directory may need to be cleaned up periodically. Under some circumstances, files may accumulate in various subdirectories, such as `.Preserve' (see section Other Spool Subdirectories) or `.Corrupt' (see section Execution Subdirectories).
Also, if a remote system stops calling in, you may want to arrange for
any queued up mail to be returned to the sender. This can be done using
uustat command (see section Invoking uustat).
The `contrib' directory includes a simple `uuclean' script which may be used as an example of a clean up script. It can be run daily out of `crontab'.
You should periodically trim the UUCP log files, as they will otherwise
grow without limit. The names of the log files are set in
`policy.h', and may be overridden in the configuration file
(see section The Main Configuration File). By default they are are
`/usr/spool/uucp/Log' and `/usr/spool/uucp/Stats'. You may
savelog program in the `contrib' directory to be of
use. There is a manual page for it in `contrib' as well.