Question about dip and lock files

Question about dip and lock files

Post by James Kaufm » Sat, 26 Feb 1994 02:25:29



Following up on my own post:



>Also, has the problem that was present in 2.2.4 in which DIP always
>locked /usr/spool/uucp/LCK..cua1 and ttyS1 been fixed so that it
>sets the lock based on the port? (eg, port cua3 should create lock
>files /usr/spool/uucp/LCK..cua3)

>JMK

I am trying to run the efax package (which seems to work fine,
by the way) but I want to set it up so that init starts up
the fax software in answer mode with the modem set to Adaptive
Answer (so it can answer both incoming fax and/or data calls.)

I am not yet successful.

However, I have noticed the following. The fax software is set up
to look for lock files in /usr/spool/uucp. If it sees either
LCK..cua3 or LCK..ttyS3 it politely steps out of the way and
allows me to use kermit (for example) to dial out. When kermit
exits, the fax software reinitializes itself. So far, so good.

DIP unfortunately has its lock files hard coded to LCK..cua1 and
LCK..ttyS1. So I figured a quick solution would be to modify
the code to use cua3, etc. This didn't work! The fax software
didn't release its hold on the port. I think that dip is setting
the lock too late. It does it in the attach.c file and should
be done in command.c when the port is chosen.

If I manually set lock files before calling dip, it works!

Further, when I modified dip to set the lock files in the do_port
routine (or whatever the actual name is - I'm at work now) I got
a "removing stale lock" message from the fax software. What
causes a stale lock? Is it caused when the PID inside the lock
file is not a currently running process? (I bet it is. I answered
my own post.)

Anyway, I think dip needs to set the lock files before the
attach subroutines are called, and use the right port. Is this
done in a newer version?

Thanks for reading this.

JMK

 
 
 

1. DIP problem: DIP creates bad lock file

It appears DIP 3.3.7 has a bug.  It creates a lock file in
/var/spool/uucp that has the wrong PID.  It should be the
PID of 'dip' but instead it puts a PID usually 1 less
than the dip PID.

Example:

dip PID = 7146
LCK..cua0 contains 7145

This will cause uucico to delete the lock file thinking it
is stale.   Then uucico can come in and interfere with the
SLIP connection.
To make things worse, uugetty would then try to reinitialize
the line after uucico finished ;-(

Is this fixed on a newer version of DIP ?

Software: Slackware 1.2, DIP 3.3.7, uugetty

--

Le Groupe Proteus        Uucp: uunet!proteus!randall
Montreal, Quebec CANADA   Voice: +1 514 630 7103,  FAX: +1 514 331 0053
186,000 miles/second.  Its not just a good idea, its the law!

2. standards smandards

3. More mail file locking questions (lockf, NFS, /var/spool/mail/*.lock)

4. Problems with pppd/chat ?

5. dip - no lock files

6. question about driver with IPAQ cradle

7. DIP questions: setup, timeout and cleanup DIP process

8. ADSL via serial ports

9. Matrox Mystique ands X.

10. dip dip dip

11. Locked files - who has it locked?

12. "Can't read lock file /tmp/.X0-lock"

13. modem locked but I can't find the lock file