[comp.unix.microport] Buggy UUCP

haugj@pigs.UUCP (Joe Bob Willie) (09/01/88)

In article <12017@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes:
>	I wouldn't claim that uucp on early versions (like 2.1.2) were
>pretty grim, but the "Telebit" uucp is solid as far as I can tell. I
>would be lieve that many sites can't support news due to disk space.

i am currently having trouble on three systems i administer with LCK..
files for the terminals getting nuked.  one of the systems runs the
"telebit" uucp.  the others don't (because they don't run xenix).

so there seems to be some collection of problems, but at least they
are common problems (1/2 :-)
-- 
=-=-=-=-=-=-=-The Beach Bum at The Big "D" Home for Wayward Hackers-=-=-=-=-=-=
               Very Long Address: John.F.Haugh@rpp386.dallas.tx.us
                         Very Short Address: jfh@rpp386
                           "ANSI C: Just say no" -- Me

daveh@marob.MASA.COM (Dave Hammond) (09/02/88)

In article <385@pigs.UUCP> haugj@pigs.UUCP (Joe Bob Willie) writes:
>i am currently having trouble on three systems i administer with LCK..
>files for the terminals getting nuked.  one of the systems runs the
>"telebit" uucp.  the others don't (because they don't run xenix).

Funny you should mention nuked LCK.. files. I just began noticing the
same thing on a system which just got updated with the TeleBit uucp.
In this case the problem occurs when non-uucp communications programs
(such as Kermit, ProComm or `CU') placed the LCK.. files there. The
new uucico (having been started from some daemon) seems to disbelieve
these `foreign' LCK.. files and unlinks them.

I've also noticed a nasty little `feature' of both the TeleBit and
older uucico programs. If the aforementioned foreign comm program
has set a lock on tty1a, and uucico is started up on tty1A -- you
will see a quick `+++' and then an `ATH0', and you find yourself
staring at `NO CARRIER'. Hmmm.

Dave Hammond
  UUCP: {uunet|...}!marob.masa.com!!daveh
DOMAIN: daveh@marob.masa.com
------------------------------------------------------------------------------

wnp@dcs.UUCP (Wolf N. Paul) (09/02/88)

In article <394@marob.MASA.COM> daveh@marob.masa.com (Dave Hammond) writes:
>In article <385@pigs.UUCP> haugj@pigs.UUCP (Joe Bob Willie) writes:
>>i am currently having trouble on three systems i administer with LCK..
>>files for the terminals getting nuked.  one of the systems runs the
>>"telebit" uucp.  the others don't (because they don't run xenix).
>Funny you should mention nuked LCK.. files. I just began noticing the
>same thing on a system which just got updated with the TeleBit uucp.
>In this case the problem occurs when non-uucp communications programs
>(such as Kermit, ProComm or `CU') placed the LCK.. files there. The
>new uucico (having been started from some daemon) seems to disbelieve
>these `foreign' LCK.. files and unlinks them.

I believe that's because of the way UUCP-related programs determine the
validity of lock files.

Pre-HDB versions (under Sys V, don't know for sure about Xenix) write
(a) their PID in a binary format ( write(fd,&PID, sizeof(PID)) ) into
the lock file, and (b) touch the lockfile regularly to make sure it
doesn't grow older than (I think) an hour. Other programs are supposed
to either check the age of the lockfile, or otherwise (if available on
your system) use the syntax kill(PID, 0) to determine if the process
owning the lock file is still alive.

HDB uucp doesn't care about the age of the lock files, but uses an
ASCII-format PID (fprintf(fp, "%10.10d\n", PID)) to identify the owner of a lock file,
and then determines the validity of that PID by means of kill(PID,0).

Most of the non-uucp communications programs I have come across
have very weak lockfile handling, and do not conform to either of these
rules. 

If you use the cu that came with your system, and the uucico that came with
your system, they should cooperate. If you acquired a different uucico
(i.e. Trailblazer), you might want to check what format the LCK..* files
are it creates -- od -c might do that. If the cu (old) uses binary PIDS
and the uucico (new) uses ASCII PIDS, you will see the symptoms you 
describe above. You need to pester your vendor for a compatible version of
cu.

If you use kermit, or pcomm, or any other public-domain comm program, 
try to get source and fix it.

Sorry I don't know how lockfiles would be handled in a DOS-under-UNIX
environment, which is the only way to run ProComm -- but again, I 
suspect that the lockfile format is incompatible.

The "+++" and "ATH" is legitimate. uucico has just tried to call once,
and has been unsuccessful because the modem, being otherwise occupied,
did not dial, or otherwise respond in a way uucico recognizes. So
uucico tries to hang up (which is what you see), and attempts to call
again. You probably should have seen the dial command from uucico a
little while before the hangup -- if you missed it, it's probably because
it had less drastic results than the hangup command.
-- 
Wolf N. Paul * 3387 Sam Rayburn Run * Carrollton TX 75007 * (214) 306-9101
UUCP:     killer!dcs!wnp                 ESL: 62832882
DOMAIN:   dcs!wnp@killer.dallas.tx.us    TLX: 910-380-0585 EES PLANO UD

chip@vector.UUCP (Chip Rosenthal) (09/02/88)

In article <394@marob.MASA.COM> daveh@marob.masa.com (Dave Hammond) writes:
>In article <385@pigs.UUCP> haugj@pigs.UUCP (Joe Bob Willie) writes:
>>i am currently having trouble on three systems i administer with LCK..
>
>the problem occurs when non-uucp communications programs
>(such as Kermit, ProComm or `CU') placed the LCK.. files there.

Strange.  I've written my own comm program, and I've never seen this
problem.  Do these things create proper lock files, i.e. containing
the PID of the lock owner?

>older uucico programs. If the aforementioned foreign comm program
>has set a lock on tty1a, and uucico is started up on tty1A...

My solution has been to lock both tty1A and tty1a.  On the flip side,
it's a really good idea for a comm program to check /etc/utmp as well
as the lock files.  With dialin/dialout lines, you can step on a dialin
unless you first verify that the line is unused.


-- 
Chip Rosenthal     chip@vector.UUCP | I've been a wizard since my childhood.
Dallas Semiconductor   214-450-0486 | And I've earned some respect for my art.

jbayer@ispi.UUCP (id for use with uunet/usenet) (09/03/88)

In article <394@marob.MASA.COM>, daveh@marob.MASA.COM (Dave Hammond) writes:
> 
> I've also noticed a nasty little `feature' of both the TeleBit and
> older uucico programs. If the aforementioned foreign comm program
> has set a lock on tty1a, and uucico is started up on tty1A -- you
> will see a quick `+++' and then an `ATH0', and you find yourself
> staring at `NO CARRIER'. Hmmm.

	Xenix (and I suspect many other Unixs) is stupid.  It doesn't
know that tty1a and tty1A both refer to the same device.  If you look at
the spool directory you will see the names of the lock files include
the device name.  Because of the case dependancy uucico will not realize
that they both are refering to the same device.

	Although I don't have the sources,  I would suspect it to be a
fairly simply  patch to  make uucp ignore case when looking at lock
files.  Hey SCO, are you listening??

Jonathan Bayer
Intelligent Software Products, Inc.
19 Virginia Ave.
Rockville Centre, NY   11570

zeeff@b-tech.UUCP (Jon Zeeff) (09/04/88)

In article <173@ispi.UUCP> jbayer@ispi.UUCP (id for use with uunet/usenet) writes:
>	Xenix (and I suspect many other Unixs) is stupid.  It doesn't
>know that tty1a and tty1A both refer to the same device.  If you look at
>the spool directory you will see the names of the lock files include
>the device name.  Because of the case dependancy uucico will not realize
>that they both are refering to the same device.

One solution is to use the same name (tty1a), but put one somewhere 
other than /dev (let's say /dev/x/tty1a).  Programs can them refer to 
/dev/tty1a or /dev/x/tty1a, depending on what they want to do.  The 
lock files don't store the directory name, so it works fine.  Note that
this same trick solves some permission problems.  Getty and uucp reset the
permissions on a line that you might want to be r/w group staff.  Creating
another device with the same name works fine.





-- 
Jon Zeeff      			Branch Technology,
umix!b-tech!zeeff  		zeeff%b-tech.uucp@umix.cc.umich.edu

biburger@quando.UUCP (Wolf-D. Biburger) (09/22/88)

In article <193@dcs.UUCP> wnp@dcs.UUCP (Wolf N. Paul) writes:
>In article <394@marob.MASA.COM> daveh@marob.masa.com (Dave Hammond) writes:
>>In article <385@pigs.UUCP> haugj@pigs.UUCP (Joe Bob Willie) writes:
>>(such as Kermit, ProComm or `CU') placed the LCK.. files there. The
>>new uucico (having been started from some daemon) seems to disbelieve
>>these `foreign' LCK.. files and unlinks them.
the problem may also occur, if those programs (kermit etc.)
place the 'LCK..'-files in '/usr/spool/uucp/' but 'uucico'
in '/usr/spool/uucp/LCK/'

>I believe that's because of the way UUCP-related programs determine the
>validity of lock files.
I don't think so - there are instructions inside the programs, to
check the existance of the 'LCK..'-file, but not any contents of it.
those 'LCK..'-files work as a semaphor (see the name....) and
if they exist a long time there may get up a 'uuclean'-process,
to check the age of all files in '/usr/spool/uucp/' see '..../crontab'

-- 
					"Wolf-Dieter Biburger"
Uad- biburger@quando.UUCP
Off- Quantum GmbH / E-Figge-Str. 83 / D-4600 Dortmund 50 / (49) +231 75 44 1 00
Prv- Am Spoerkel 61 / D-4600 Dortmund 50 / +231 75 41 03

james@bigtex.uucp (James Van Artsdalen) (09/23/88)

In article <641@quando.UUCP>, biburger@quando.UUCP (Wolf-D. Biburger) wrote:

> I don't think so - there are instructions inside the programs, to
> check the existance of the 'LCK..'-file, but not any contents of it.

No.

> those 'LCK..'-files work as a semaphor (see the name....) and
> if they exist a long time there may get up a 'uuclean'-process,

Not correct on modern UUCPs (perhaps true for old ones though).

The contents of the LCK.. file are significant.  In HDB uucp the
contents correspond to the printf control string "%10d\n" and the
content id the PID of the locking process.  Other processes use the
content to determine if the lock is valid by using kill(PID, 0) and
checking for an error.  Therefore, invalid contents of the lock file
will cause an invalid PID to be read, which will prevent the locking
process from being found by kill(), and uucico will remove the lock.

Older UUCPs did not use the (relatively new) capability of kill to
detect the existence of a process, and hence simply assumed that a
lock was "stale" if it was old enough.  "Old enough" often meant an
hour or two.  This scheme doesn't terribly well.
-- 
James R. Van Artsdalen	...!uunet!utastro!bigtex!james	"Live Free or Die"
Phone: 512-346-2444		  10926 Jollyville Rd #901 Austin TX 78759