matt@ncr-sd.SanDiego.NCR.COM (Matt Costello) (01/05/88)
HDB UUCP has a tendency to run out of processes when there are
a large number of simultaneous connections possible. I've seen
this occur often enough to be anoying, since it manifests as a
random failure in uux. The problem is that there is no settable
limit on the number of simultaneous uucico's. I've seen this
using Honey DanBer UUCP, but I expect the same problem exists
in all other versions of UUCP as well.
To duplicate this failure mail a message to the number of machines
that exceeds the process limit for a single user (your limits will
vary). Normally then number of incoming and outgoing modems (or tty
lines) limits the number of simulateous uucico's. When UUCP is
run across an ethernet the number of connections becomes limited
by either the number of sockets or the maximum number of uucp
processes. If the later, then the fork/exec needed to transport
mail using uux is liable to fail since the limit on processes
has been exceeded.
The "-r" option to uucp and uux will (mostly) solve the problem
by not starting uucico's, but with the disadvantage that mail
will not be delayed until the next uusched comes along. Does
anyone know of a simple fix for this problem? Adding a Maxuucicos
value similar to Maxuuscheds and Maxuuxqts seems to be the
only feasible solution.
--
Matt Costello <matt.costello@SanDiego.NCR.COM>
+1 619 485 2926 <matt.costello%SanDiego.NCR.COM@Relay.CS.NET>
{sdcsvax,cbosgd,pyramid,nosc.ARPA}!ncr-sd!matthoney@umix.cc.umich.edu (Peter Honeyman) (01/06/88)
Maxuucicos is a good idea. ber's cuantos function in uuxqt.c will probably come in handy. or you could make uucp's uid 0, but i've never tried this and don't recommend it. or you could increase the per-user process limit. peter