From owner-freebsd-current  Thu Jul  6 22:23:43 1995
Return-Path: current-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id WAA17591
          for current-outgoing; Thu, 6 Jul 1995 22:23:43 -0700
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id WAA17583
          for <freebsd-current@freebsd.org>; Thu, 6 Jul 1995 22:23:07 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id PAA06214 for freebsd-current@freebsd.org; Fri, 7 Jul 1995 15:21:13 +1000
Date: Fri, 7 Jul 1995 15:21:13 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199507070521.PAA06214@godzilla.zeta.org.au>
To: freebsd-current@freebsd.org
Subject: Re: /etc/rc and "rm -f /var/spool/lock/*"
Sender: current-owner@freebsd.org
Precedence: bulk

>> My /var/spool/fax/etc/config.ttyd1 (for hylafax) has:
>> 	UUCPLockDir     /var/spool/lock # jhs added this after seeing where kermit created a lock.
>> I haven't got round to checking if I need it.

>If it's outgoing-only, it isn't needed.  If it's also able to receive
>incoming fax messages, i guess you're going to use mgetty anyway.
>mgetty needs the lock files, since it cannot use the dialin port (it
>has to watch modem messages even while the modem is in the `not
>connected' state).

Er, mgetty is supposed to be used on the dialin port.  It does everything
necessary to listen to the modem: open the port with O_NONBLOCK; set CLOCAL;
clear O_NONBLOCK; listen to modem; then when connection is detected: clear
CLOCAL; read and write to the connection.

The last step apparently suffers from a race under FreeBSD-2.0:
sometimes the connection is detected (according to the modem's messages)
a long time (several tenths of a second) before carrier rises, and the
connection isn't fully established before it is used.  read() and
write() terminate prematurely (as if the connection were closed) in
FreeBSD-2.0.  mgetty should probably worry more about the race because
the semantics of read/write to a non-established connection (that must
have been partially opened using O_NONBLOCK etc.) aren't clearly defined
The problem was fixed in 1.1.5 by DTRT (blocking) for read/write to
non-established connections.

Bruce