lmb@vicom.com (Larry Blair) (07/11/90)
Has anyone tried running 2 different system's uucp with a common spool directory? Do anyone know why it wouldn't work? Right now I have one Sun system which runs my uucp and has the spool directory. For performance reasons, it still runs 3.5.2. What I would like to do is to NFS mount the spool directory on a Sparc w/4.0.3. The second system is only for transmission. Actual uucp requests would only execute one the first system, so there won't be a problem with the SEQF. It seems to me that the LCK.. files would work O.K. over NFS and would prevent race conditions. What am I missing? -- Larry Blair ames!vsi1!lmb lmb@vicom.com
urlichs@smurf.sub.org (Matthias Urlichs) (07/13/90)
In comp.mail.uucp, article <1990Jul11.163251.19026@vicom.com>,
lmb@vicom.com (Larry Blair) writes:
< Has anyone tried running 2 different system's uucp with a common spool
< directory? Do anyone know why it wouldn't work?
<
Lots of reasons, unfortunately.
- The temporary lock file name is based on the process ID. Depending on how
intelligent your UUCP is, this can result in a failure to execute (benign)
or a failure to lock (possibly fatal).
- The permanent lock file contains the process ID of the process owning the
lock. Even if you could ensure a common format, which you can't, the lock
will be automatically deleted if the process isn't running on the machine
the lock file is checked at.
- Don't forget that different UUCP implementations may have differing ideas on
where to put the job files. (I know of at least four.) This affects both
uux->uucico and uucico->uuxqt. Symlinks may help a lot here.
Your only options are:
- Machine A does uucico, Machine B does uuxqt, Machine C does uux/uucp.
A, B, and C don't have to be distinct, but they must be unique, meaning that
no two machines may do the same thing. (Delete the forbidden programs to
make sure they won't.)
- Given (a) source code and (b) an implementation of NFS which gets locking
right, implement a more sensible locking scheme. (Detecting dead locks is
itself a nontrivial problem.)
- On the host which creates the jobs, replace uux with a shell script which
executes uux on the "real" uucp machine, via rsh or similar. Likewise,
create special versions of rmail and/or rnews on the uucp machine which
execute the respective program on the system where they have to go.
Personally, I'd recommend the latter method.
--
Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(Voice)/621227(PEP)