From: gerg@netcom.com (Greg Andrews)
Newsgroups: biz.sco.general
Subject: Re: getty writing a LCK file
Date: 26 Jan 93 07:57:14 GMT
Organization: Netcom Online Communications Services (408-241-9760 login: guest)

kevinc@ups.com (Kevin C. Castner) writes:
>Jean-Pierre Radley (jpr@jpradley.jpr.com) wrote:
>:Kevin C. Castner writes:
>:> 
>:> If I move real fast, I can see uuchat start and end.  The pid in the LCK 
>:> file is originally that of uuchat, and then changes to that of getty.
>:> The thing that really bothers me is that the LCK file is named LCK..tty1a
>:> and not tty1A where getty is running.
>: 
>:This is correct too. Whether you call out (say with cu) on tty1a or tty1A,
>:the LCK..file will use the lower-case name either way.
>
>Getty shouldn't leave a LCK file.  When cu or uucico want to get to the line,
>they look for a lock file, and if it is there they quit (as long as it's
>not a stale lock file).
>

I'm afraid that's not right, Kevin.  Getty *MUST* write a lock file.
Why?  Consider the situation when someone has dialed in through the
modem.  What will happen if cron fires up a uucp session?

If getty has not opened a lock file for the modem port, uucico will
open the modem port and spew AT commands at the dial-in user's screen!

So getty (in SCO Unix 3.4 v4.x and ODT 2.x - uugetty in previous versions)
must open a lock file when it grabs control of the modem port.  (/etc/getty
in previous versions was a version of the original Unix getty, which was
written before cu and uucico existed - hence didn't open lock files for
them)

How does a sysadmin prevent a conflict between getty grabbing control of
the modem port and not letting cu/uucico have their chance?  Read further:

>
>I'm not up on all the specifics, but getty "watches" the line, and if
>another process grabs it, getty kills itself and is later restarted by
>inittab when the LCK file is deleted by the other process.
>

That explanation is WAY oversimplified.  Getty doesn't "watch" the line.
    (1) Getty is spawned by init.

    (2) Getty makes a call to the device driver for the modem port, asking
	the driver to open the port for sending and receiving bytes.  The
	driver does not immediately return control back to getty.  Getty
	is in a coma, so to speak.

    (3) When the modem's DCD signal turns on, the driver returns from the
	call, bringing getty back from its coma.

    (4) Getty continues, unaware that time passed, and it checks the spool
	directory to see if a lock file is already open.  If not, getty
	decides to open its own lock file and send out a login prompt.

The key to solving the problem you had is in understanding the transition
from Step 2 to Step 3.  If a good amount of time elapses between Step 2
and Step 3, cu and uucico have a chance to use the port.  If little or no
time elapses between Step 2 and Step 3, getty opens its lock file before
cu or uucico get their chance.

What are some of the things that can allow Step 3 to happen immediately
after Step 2?

	o CLOCAL is set in the /etc/gettydefs entry (this actually
	  changes the driver's behavior so it pretends DCD is already
	  on and returns immediately).

	o The tty1a port is used instead of tty1A (actually, the port device
	  getty opens has a minor number < 128).  This is very similar to
	  having CLOCAL set (above).

	o The modem's DCD signal is already on when getty opens the port.
	  The conditions for returning from the open call are immediately
	  satisfied, so the driver returns immediately, and getty opens
	  its lock file immediately.

	o The RS232 cable is wired such that the incoming DCD signal is
	  always on.  (Looping DTR back to DCD can accomplish this, as
	  can connecting the computer's DCD pin to a different pin on
	  the modem.  E.g. to DSR.)

	o The driver for a multiport board has been configured to pretend
	  DCD is on no matter what the CLOCAL, tty1a/tty1A, or modem DCD
	  configuration is.  (Not very common, but it happens)

>
>With that said, the problem turned out to be a modem configuration problem.
>I had CD set to be always high.  I set register 131 on the T2500 to 1 and
>getty is now removing it's lock file.  Thanks to Brian Murrell and
>Bela Lubkin for the mail that explained the CD interpretation.
>
>From a different post, someone mentioned that I should be using uugetty.
>In 2.0, uugetty is a shell script that calls /etc/getty.
>
>Thanks again for all the help.
>

Perhaps you would benefit from asking modems@telebit.com for the current
SCO setup guide.  It doesn't explain the operating system stuff I outlined
above, but it does direct the user to use tty1A without CLOCAL, and register
settings like S131=1.

  -Greg
(Telebit Engineer)
-- 
:::::::::::::::::::  Greg Andrews  gerg@netcom.com  :::::::::::::::::::
ObGuindon:  "Hi!  I'm Bob and I need someone to talk to because I've just
            finished this week's People magazine and my mind is racing."
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::