UUCPLOCK(3)

UUCPLOCK(3) 💅

okay bestie, welcome to the Library Functions Manual page for the serial-device lock girlies. this one is all about acquiring and releasing control of a serial device, and it is lowkey a whole vibe. let’s get into it. 🦋

🎀 NAME 🎀

uu_lock, uu_lock_txfr, uu_unlock, uu_lockerr — the little squad that handles acquiring and releasing control of a serial device. periodt. ✨

📚 LIBRARY 📚

System Utilities Library (libutil, -lutil) — yes bestie, that’s the one. link it with -lutil. 🫶

🌸 SYNOPSIS 🌸

#include <sys/types.h>
#include <libutil.h>

int
uu_lock(const char *ttyname);

int
uu_lock_txfr(const char *ttyname, pid_t pid);

int
uu_unlock(const char *ttyname);

const char *
uu_lockerr(int uu_lockresult);

💖 DESCRIPTION 💖

the uu_lock() function tries to create a lock file called /var/spool/lock/LCK.. with a suffix given by the passed ttyname. if that file already exists, it is expected to contain the process id of the locking program. like, that’s the whole point. 👑

if the file does not already exist, or the owning process given by the process id found in the lock file is no longer running, uu_lock() will write its own process id into the file and return success. slay. ✅

uu_lock_txfr() transfers lock ownership to another process. uu_lock() must have previously been successful. no skipping steps, bestie. 💅

uu_unlock() removes the lockfile created by uu_lock() for the given ttyname. care should be taken that uu_lock() was successful before calling uu_unlock(). like pls check first, okay? 🙈

uu_lockerr() returns an error string representing the error uu_lockresult, as returned from uu_lock(). it’s giving “translator for your lock result.” 🧚

🔥 RETURN VALUES 🔥

uu_unlock() returns 0 on success and -1 on failure. simple. iconic. 💀

uu_lock() may return any of the following values:

• UU_LOCK_INUSE — the lock is in use by another process. someone else has the aux cord. 😭
• UU_LOCK_OK — the lock was successfully created. we love a win. 🎀
• UU_LOCK_OPEN_ERR — the lock file could not be opened via open(2).
• UU_LOCK_READ_ERR — the lock file could not be read via read(2).
• UU_LOCK_CREAT_ERR — cannot create temporary lock file via creat(2).
• UU_LOCK_WRITE_ERR — the current process id could not be written to the lock file via a call to write(2).
• UU_LOCK_LINK_ERR — cannot link temporary lock file via link(2).
• UU_LOCK_TRY_ERR — locking attempts are failed after 5 tries. five strikes and you’re out, bestie. 💅

if a value of UU_LOCK_OK is passed to uu_lockerr(), an empty string is returned. otherwise, a string specifying the reason for failure is returned. uu_lockerr() uses the current value of errno to determine the exact error.

care should be made not to allow errno to be changed between calls to uu_lock() and uu_lockerr(). like do not let anything mess with it in between. that’s the rule. 🫶

uu_lock_txfr() may return any of the following values:

• UU_LOCK_OK — the transfer was successful. the specified process now holds the device lock. handing over the crown. 👑
• UU_LOCK_OWNER_ERR — the current process does not already own a lock on the specified device. you can’t transfer what you don’t have, bestie. 🙈
• UU_LOCK_WRITE_ERR — the new process id could not be written to the lock file via a call to write(2).

⚠️ ERRORS ⚠️

if uu_lock() returns one of the error values above, the global value errno can be used to determine the cause. refer to the respective manual pages for further details. iykyk. 🔍

uu_unlock() will set the global variable errno to reflect the reason that the lock file could not be removed. refer to the description of unlink(2) for further details. yes, that unlink(2). 💅

🦋 SEE ALSO 🦋

lseek(2), open(2), read(2), write(2)

🌈 HISTORY 🌈

the functions uu_lock(), uu_unlock() and uu_lockerr() first appeared in FreeBSD 2.0.5. vintage. iconic. ate. ✨

💀 BUGS 💀

it is possible that a stale lock is not recognised as such if a new process is assigned the same process id as the program that left the stale lock. yes, that can happen. awkward. 😭

the calling process must have write permissions to the /var/spool/lock directory. there is no mechanism in place to ensure that the permissions of this directory are the same as those of the serial devices that might be locked. so like, permissions check yourself before you wreck yourself. 🫶

---

okay bye bestie — this page is Debian, dated May 10, 2020, and you already know the title: UUCPLOCK(3). mwah. 🎀💖