uugetty & Respawning

uugetty & Respawning

Post by Mike Mik » Thu, 25 Jul 1996 04:00:00



We are trying to bring up an AT&T Globalyst 575 (NCR) i486 with 500
meg PCI Scsi card - 16 megs RAM PC with version 1.2.13 Slackware.

It installed and runs fine but we can't get uugetty to work with any
of the serial ports (On board or Installed).  We've tried installing a
serial card and turning OFF the onboard ports.  But no matter what we
do the same thing happens.   On boot up linux finds the ports and sets
them up as devices (cua's).  When uugetty tries to run - you can see
it briefly in the process list - then it says that it is respawning
too fast and is disabled for 5 minutes.

We sure could use some help and any hints would be appreciated.
TIA =mm=

 
 
 

uugetty & Respawning

Post by Mike Mik » Thu, 25 Jul 1996 04:00:00


We figured it out.   It had to do with the syntax in our gettydefs
file.   THX anyways

 
 
 

uugetty & Respawning

Post by Vern Hox » Sun, 04 Aug 1996 04:00:00



>We are trying to bring up an AT&T Globalyst 575 (NCR) i486 with 500
>meg PCI Scsi card - 16 megs RAM PC with version 1.2.13 Slackware.

>It installed and runs fine but we can't get uugetty to work with any
>of the serial ports (On board or Installed).  We've tried installing a
>serial card and turning OFF the onboard ports.  But no matter what we
>do the same thing happens.   On boot up linux finds the ports and sets
>them up as devices (cua's).  When uugetty tries to run - you can see
>it briefly in the process list - then it says that it is respawning
>too fast and is disabled for 5 minutes.

>We sure could use some help and any hints would be appreciated.
>TIA =mm=

Don't use 'uugetty'.  Try my 'getty_em' for simple call in usage or
'mgetty' if you want whole ball of wax (data, fax and voice).

'Getty_em' is part of a collection serial utilities I have assembled into a
file named 'serial_suite.tgz'.  It is available via ftp from
'scicom.alphacdc.com'.

The collection includes blurbs about setting up the ports and modems.

The problem you are experiencing is the manner which 'uugetty' opens the
driver and the modems DCD.  See the attached blurb.

Don't use 'cua*' or '/dev/modem' for outgoing calls.

------------------------

Two different methods have been developed in an attempt to avoid having
more than one process running on the same serial port at a time.  One
method was developed at AT&T by their uucico developers.  The other was
apparently developed at Berkely for the BSD system.  This method was
adopted by Sun and others including Linux.

Under the AT&T Unix, the problem was solved by using 'lockfiles'.  These
are simple files which contain the PID of the process using the port.  The
idea is that if the PID which created the lockfile is still active, other
processes should wait.  On Linux. these lockfiles are kept in the
/var/lock/uucp directory.  The names are 'LCK..ttyS0' etc.  Under this
system, only one device driver is used per port.

When a process wants to use the port, it first checks for a lockfile on the
device it wants to use.  If it find a file, it reads the PID recorded
therein and checks if the process is still active or not.  If the process
still exists, the new process quits.  If the old process has died, the
lockfile is removed and a new one created.

The technique for creating lockfiles is to first create a temporary file
complete with the PID written to it.  This file is then linked to the
desired 'LCK..ttySN' name.  If some other process also wants this port and
has created their own lockfile, our link will fail.

Under the BSD/Sun versions of Unix, two device drivers are provided for
each port.  Presumably one is for 'outgoing' calls and the other for
'incoming' calls.  Under Linux, these drivers use the same coding and are
identical except for a kernel lock.  The operation of this locking method
is very complicated and I am not sure I know all the side effects even
though I have studied the code extensively.

First, it is necessary to understand that the 'open(2)' system call has a
special flag when the file is a bolck special or character special device
driver.  This flag is 'O_NONBLOCK' or 'O_NDELAY'.  With respect to serial
devices, this means that a normal 'open' will block and not return until
the Data Carrier Detect (DCD) line is asserted.  If 'O_NONBLOCK' flag is
included in the open command, the call will return immediately regardless
of the status of the DCD line.

If the struct termios CLOCAL (see termios.blurb) option has been selected,
the O_NONBLOCK flag is ignored.

In Linux, whenever the NORMAL (ttySN) device is neither open nor blocking
on an open and an attempt is made to open the CALLOUT (cuaN) device, it
will open immediately regardless of the presence or absence of the
O_NOBLOCK flag.  However if the NORMAL device is active or blocking on a
read (see VMIN=1, VTIM=0 in 'termios.blurb'), an open on the CALLOUT device
will fail and return an EBUSY error code.

On the other hand, if the CALLOUT device is open (O_NONBLOCK doesn't
appear to be a factor), an attempt to open the NORMAL driver will fail and
return the EBUSY error code.

Thus, if you have a 'getty' listening on the 'incoming' line, it is
impossible to place a call on the 'outgoing' driver.  However, if you place
your outgoing call on the 'incoming' driver, it will open and proceed
normally.  That is 'normally', if the 'getty' is smart enough to get off
the line.  The AT&T 'uugetty' (not the Linux uugetty) expect that the first
characters received on incoming calls are either newlines or carriage
returns.  If any other characters are received, they are assumed to be
outgoing characters and the 'getty' graciously exits.

I have been carrying on a discussion for the last couple of months about the
need for 'cuaN and ttySN' drivers and so far I haven't received a
convincing reason that there is an need for the 'cuaN' series.  All the
communication software provided with Linux, recognize the /var/lock/uucp
lockfiles anyhow.

I hope that this clarifies the situation somewhat.  As far as I am
concerned, the only value the 'cuaN' and the 'Serial-HOWTO' is to confuse
immigrants from DOS.  I immigrated from AT&T SYSV and it confused me.

If you try to open a callout driver when the associated 'callin' driver is
opened, the open returns EBUSY.  If the normal driver is opened in blocking
mode, and the callout driver is busy, the attempt to open will fail with
EBUSY.  However, if it opened in standard (blocking) mode, the open will
block until the ports DCD line is asserted.  For non-blocking mode and the
cuaN port is inactive, the open will succeed immediately.  

The problem is partly cultural and partly an attempt to state a complex
situation in simply words.

The problem is "How to prevent incoming call and outgoing calls on a single
port from colliding".

-----------------------

vern

--
Vernon C. Hoxie                                           scicom!zebra!vern

Denver, Colo., 80212        uucp: 303-455-2670          voice: 303-477-1780
               Unix is what MSDOS will be when it grows up.

 
 
 

1. uugetty & respawning too fast

I am running Linux as a dial-in PPP server with uugetty 2.0.7i.
With DEBUG=010 all works fine , but turning off uugetty debugging  my
syslog report messages that says "d2 respawning too fast.. disabled
for 5 minutes"

any suggestion ?

2. ???problems receiving external mail with postfix on linux1 2.2.13-4mdk

3. uugetty respawning

4. Oops: Bourne Backgrounding

5. Respawning uugetty

6. Slow tranferrates with PPP

7. uugetty respawns too quickly and dies. Why?

8. Samba client of Win2K FAT shares

9. uugetty constantly respawning

10. uugetty respawning to fast if modem turned off

11. uugetty respawning..solved

12. UUGETTY respawning too rapidly?

13. INIT respawn uugetty too fast!!!!