Search the FAQ Archives

3 - A - B - C - D - E - F - G - H - I - J - K - L - M
N - O - P - Q - R - S - T - U - V - W - X - Y - Z
faqs.org - Internet FAQ Archives

UUCP Internals Frequently Asked Questions
Section - UUCP Lock Files

( Single Page )
[ Usenet FAQs | Web FAQs | Documents | RFC Index | Cities ]


Top Document: UUCP Internals Frequently Asked Questions
Previous Document: UUCP Grades
Next Document: Execution File Format
See reader questions & answers on this topic! - Help others by sharing your knowledge
UUCP Lock Files
===============

This discussion applies only to Unix.  I have no idea how UUCP locks
ports on other systems.

UUCP creates files to lock serial ports and systems.  On most, if not
all, systems, these same lock files are also used by `cu' to coordinate
access to serial ports.  On some systems `getty' also uses these lock
files, often under the name `uugetty'.

The lock file normally contains the process ID of the locking process.
This makes it easy to determine whether a lock is still valid.  The
algorithm is to create a temporary file and then link it to the name
that must be locked.  If the link fails because a file with that name
already exists, the existing file is read to get the process ID.  If the
process still exists, the lock attempt fails.  Otherwise the lock file
is deleted and the locking algorithm is retried.

Older UUCP packages put the lock files in the main UUCP spool directory,
`/usr/spool/uucp'.  HDB UUCP generally puts the lock files in a
directory of their own, usually `/usr/spool/locks' or `/etc/locks'.

The original UUCP lock file format encodes the process ID as a four byte
binary number.  The order of the bytes is host-dependent.  HDB UUCP
stores the process ID as a ten byte ASCII decimal number, with a
trailing newline.  For example, if process 1570 holds a lock file, it
would contain the eleven characters space, space, space, space, space,
space, one, five, seven, zero, newline.  Some versions of UUCP add a
second line indicating which program created the lock (`uucp', `cu', or
`getty/uugetty').  I have also seen a third type of UUCP lock file
which does not contain the process ID at all.

The name of the lock file is traditionally `LCK..' followed by the base
name of the device.  For example, to lock `/dev/ttyd0' the file
`LCK..ttyd0' would be created.  On SCO Unix, the lock file name is
always forced to lower case even if the device name has upper case
letters.

System V Release 4 UUCP names the lock file using the major and minor
device numbers rather than the device name.  The file is named
`LK.XXX.YYY.ZZZ', where XXX, YYY and ZZZ are all three digit decimal
numbers.  XXX is the major device number of the device holding the
directory holding the device file (e.g., `/dev').  YYY is the major
device number of the device file itself.  ZZZ is the minor device
number of the device file itself.  If `s' holds the result of passing
the device to the stat system call (e.g., `stat ("/dev/ttyd0", &s)'),
the following line of C code will print out the corresponding lock file
name:
         printf ("LK.%03d.%03d.%03d", major (s.st_dev),
                 major (s.st_rdev), minor (s.st_rdev));
The advantage of this system is that even if there are several links to
the same device, they will all use the same lock file name.

When two or more instances of `uuxqt' are executing, some sort of
locking is needed to ensure that a single execution job is only started
once.  I don't know how most UUCP packages deal with this.  Taylor UUCP
uses a lock file for each execution job.  The name of the lock file is
the same as the name of the `X.*' file, except that the initial `X' is
changed to an `L'.  The lock file holds the process ID as described
above.

User Contributions:

Comment about this article, ask questions, or add new information about this topic:

CAPTCHA




Top Document: UUCP Internals Frequently Asked Questions
Previous Document: UUCP Grades
Next Document: Execution File Format

Single Page

[ Usenet FAQs | Web FAQs | Documents | RFC Index ]

Send corrections/additions to the FAQ Maintainer:
ian@airs.com (Ian Lance Taylor)





Last Update March 27 2014 @ 02:12 PM