Run uuidd Safely with a Private Test Socket

You will start uuidd with a temporary PID file and Unix socket, request random and time-based UUIDs, check the exit status, and stop the daemon. The workflow takes about ten minutes and leaves the machine's normal service configuration alone.

The examples use the locally installed uuidd from util-linux 2.42.4. The Debian package database on this machine reports uuid-runtime 2.39.3-9ubuntu6.6, so check your executable and package separately if their versions differ. This guide follows the installed command and its uuidd(8) manual.

You need a shell and permission to write to /tmp. Ordinary users can run every command below. Use sudo only if you deliberately choose a protected runtime directory or are inspecting a system-managed daemon. Do not test by killing a daemon that belongs to another service.

1. Check the executable and version

Confirm which binary is first in your PATH, then inspect its version. These are read-only commands:

$ command -v uuidd
/usr/bin/uuidd
$ uuidd --version
uuidd from util-linux 2.42.4
$ dpkg-query -W -f='${Package} ${Version}\n' uuid-runtime
uuid-runtime 2.39.3-9ubuntu6.6

The package query is Debian and Ubuntu specific. On another distribution, use its package manager or omit that check. The important value for the options you are about to use is the version printed by the executable.

2. Choose private runtime paths

The daemon normally uses a runtime directory controlled by the installation, and the libuuid client expects a conventional socket path. For a manual test, the -p and -s options let you isolate the daemon in /tmp. The manual describes these paths as primarily for debugging.

$ PIDFILE=/tmp/uuidd-guide.pid
$ SOCKET=/tmp/uuidd-guide.socket
$ printf 'pid file: %s\nsocket: %s\n' "$PIDFILE" "$SOCKET"
pid file: /tmp/uuidd-guide.pid
socket: /tmp/uuidd-guide.socket

Pick names that are not already in use. If a previous test left either path behind, inspect it before starting anything:

$ ls -l "$PIDFILE" "$SOCKET"
ls: cannot access '/tmp/uuidd-guide.pid': No such file or directory
ls: cannot access '/tmp/uuidd-guide.socket': No such file or directory

Your output is allowed to differ. If either path exists, do not remove it blindly. It may belong to a running process or another user.

3. Start the daemon

Start uuidd without -d. It daemonises using a double fork and returns to your shell:

$ uuidd -p "$PIDFILE" -s "$SOCKET" -T 30
$ printf 'start status: %s\n' "$?"
start status: 0
$ ls -l "$PIDFILE" "$SOCKET"
-rw-r--r-- 1 user user 9 Sep 27 17:50 /tmp/uuidd-guide.pid
srwxrwxrwx 1 user user 0 Sep 27 17:50 /tmp/uuidd-guide.socket

The exact owner, timestamp and PID file size vary. A zero exit status means the launch request succeeded. The -T 30 option makes the daemon exit after 30 seconds of inactivity, which limits the chance of leaving this test process running. It is not a replacement for stopping it explicitly.

4. Request random UUIDs

Use -d on the test request so the client-side test runs in the foreground. The daemon itself is still the process started in the previous step:

$ uuidd -d -r -n 3 -s "$SOCKET"
List of UUIDs:
	875a70cf-8dfe-4be8-a6ec-917f628b1696
	51b0b919-7a50-45e4-bf9b-7142c5759530
	7cd6d13c-8969-46f2-9be5-de0fd1f8ca0f
$ printf 'random test status: %s\n' "$?"
random test status: 0

The values are examples, not fixed output. With -n 3, expect three UUIDs under the List of UUIDs: label. Change the number when you need a different bulk request. Do not parse the sample UUIDs as identifiers that will recur on your host.

Use uuidgen when you simply need UUIDs for an application or script. This guide uses the uuidd test options because they verify communication with the daemon over the selected socket.

5. Request a time-based UUID

Run the corresponding time-based request:

$ uuidd -d -t -s "$SOCKET"
949126b8-ba93-11f1-8ace-901b0edaccef
$ printf 'time test status: %s\n' "$?"
time test status: 0

A time-based UUID commonly has a version field of 1, visible as the first hexadecimal digit of its third group. The daemon exists to help the UUID library generate time-based values securely and uniquely when many processes or threads request them. The printed value and clock-related fields will vary.

6. Stop the test daemon

Stop only the daemon attached to your private socket:

$ uuidd -d -k -s "$SOCKET"
Killed uuidd running at pid 12345.
$ printf 'stop status: %s\n' "$?"
stop status: 0
$ ls -l "$PIDFILE" "$SOCKET"
ls: cannot access '/tmp/uuidd-guide.pid': No such file or directory
ls: cannot access '/tmp/uuidd-guide.socket': No such file or directory

The reported PID and the removal timing vary. If the paths remain, wait briefly and inspect them again. Do not kill a PID copied from a stale file. If the daemon has already exited because of -T 30, the kill request may fail; that is a state to investigate, not a reason to target another daemon.

This example changes runtime state only. There is no persistent configuration to undo. If you used different paths, keep them recorded until you have verified that the matching daemon is gone.

7. Understand the options that change the workflow

-F prevents daemonisation and is useful for foreground debugging. -P prevents creation of a PID file. -S expects systemd to provide the socket and implies -F and -P; do not use it in a hand-started shell test. The manual says socket activation needs to be enabled at build time and is intended for systemd.

-C enables continuous clock handling for time-based UUIDs. Without an argument it uses a maximum clock offset of two hours. An explicit value is expressed in seconds, or in hours or days with h or d; the documented range is 60 seconds to 365 days. This is a behaviour choice for a real deployment, not an option to add casually to a smoke test.