Path: utzoo!censor!geac!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!apple!usc!orion.oac.uci.edu!ucivax!gateway
From: jns@fernwood.mpk.ca.US (Jerry Sweet)
Newsgroups: comp.sys.mips
Subject: uugetty and /usr/spool/locks
Message-ID: <9101111107.AA09005@fernwood.mpk.ca.us>
Date: 11 Jan 91 20:32:24 GMT
Lines: 25


For me, this note applies to RISC/os 4.51 on an RC3230.

The man page for uugetty, as well as the Nutshell handbook, leads one
to believe that uugetty will "step aside" for other processes that
wish to use a modem port for which a uugetty process is awaiting login
(presumably via "respawn" in the inittab).  This appears not to be the
case.  Uugetty, while waiting for login, leaves a lock file in
/usr/spool/locks.

Kermit, of course, wants to put its lock file in the standard place,
/usr/spool/uucp.  If you request the same line for which there is a
uugetty process, you're out of luck---it'll just sit there waiting
for...what?  The device to be closed?

The question is: how does one properly make the alleged "step-aside"
feature of uugetty happen?  Does one have to (a) leave the port "off"
in inittab, put up a uugetty only when one is done dialling out on a
port, and then kill the uugetty if one wishes dial out on the same
port again?  or (b) kill the uugetty job for that port and quickly try
to grab it before init spawns another uugetty? or (c) do the tedious
thing of having two inittabs, one with uugetty off and one with
uugetty on, etc., etc. ...?

Perplexed in Menlo Park...