If your system supports pseudo-terminals, and you compiled the code to
support the new style of configuration files (HAVE_TAYLOR_CONFIG
was set to 1 in `policy.h'), you should be able to use the
tstuu program to test the uucico daemon. If your system
supports STREAMS based pseudo-terminals, you must compile tstuu.c with
`-DHAVE_STREAMS_PTYS'. (The STREAMS based code was contributed by
Marc Boucher).
To run tstuu, just type `tstuu' with no arguments. You must
run it in the compilation directory, since it runs `./uucp',
`./uux' and `./uucico'. The tstuu program will run a
lengthy series of tests (it takes over ten minutes on a slow VAX). You
will need a fair amount of space available in `/usr/tmp'. You will
probably want to put it in the background. Do not use ^Z, because
the program traps on SIGCHLD and winds up dying. The
tstuu program will create a directory `/usr/tmp/tstuu' and
fill it with configuration files, and create spool directories
`/usr/tmp/tstuu/spool1' and `/usr/tmp/tstuu/spool2'.
If your system does not support the FIONREAD call, the
`tstuu' program will run very slowly. This may or may not get
fixed in a later version.
The tstuu program will finish with an execute file named
`X.something' and a data file named `D.something'
in the directory `/usr/tmp/tstuu/spool1' (or, more likely, in
subdirectories, depending on the choice of SPOOLDIR in
`policy.h'). Two log files will be created in the directory
`/usr/tmp/tstuu'. They will be named `Log1' and `Log2',
or, if you have selected HAVE_HDB_LOGGING in `policy.h',
`Log1/uucico/test2' and `Log2/uucico/test1'. There should be
no errors in the log files.
You can test uuxqt with `./uuxqt -I /usr/tmp/tstuu/Config1'.
This should leave a command file `C.something' and a data
file `D.something' in `/usr/tmp/tstuu/spool1' or in
subdirectories. Again, there should be no errors in the log file.
Assuming you compiled the code with debugging enabled, the `-x'
switch can be used to set debugging modes; see the debug command
for details (see section Debugging Levels). Use `-x all' to turn on
all debugging and generate far more output than you will ever want to
see. The uucico daemons will put debugging output in the files
`Debug1' and `Debug2' in the directory `/usr/tmp/tstuu'.
After that, you're pretty much on your own.
On some systems you can also use tstuu to test uucico
against the system uucico, by using the `-u' switch. For
this to work, change the definitions of ZUUCICO_CMD and
UUCICO_EXECL at the top of `tstuu.c' to something
appropriate for your system. The definitions in `tstuu.c' are what
I used for Ultrix 4.0, on which `/usr/lib/uucp/uucico' is
particularly obstinate about being run as a child; I was only able to
run it by creating a login name with no password whose shell was
`/usr/lib/uucp/uucico'. Calling login in this way will leave fake
entries in `wtmp' and `utmp'; if you compile `tstout.c'
(in the `contrib' directory) as a setuid root program,
tstuu will run it to clear those entries out. On most systems,
such hackery should not be necessary, although on SCO I had to su to
root (uucp might also have worked) before I could run
`/usr/lib/uucp/uucico'.
You can test uucp and uux (give them the `-r' switch
to keep them from starting uucico) to make sure they create the
right sorts of files. Unfortunately, if you don't know what the right
sorts of files are, I'm not going to tell you here.
If you can not run tstuu, or if it fails inexplicably, don't
worry about it too much. On some systems tstuu will fail because
of problems using pseudo terminals, which will not matter in normal use.
The real test of the package is talking to another system.
Go to the first, previous, next, last section, table of contents.