Run uuidd Safely with a Private Test Socket

Kill the wrong uuidd and you take down every app on the box asking for an identifier, so this guide keeps the whole test on a private socket. You will start the daemon, ask for both UUID types it can hand out, check exit status, and stop it again, all without touching the machine's real service.

• A shell and permission to write to /tmp.
• About ten minutes.
• No sudo, unless you deliberately pick a protected runtime directory or are inspecting a system-managed daemon.

Do not test this 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. Both commands are read-only:

$ 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: use your own package manager, or skip it, on another distribution. The version that matters for the options below is the one the executable itself prints, and this guide follows that installed command and its uuidd(8) manual.

2. Choose private runtime paths

The daemon normally runs from an installation-controlled runtime directory, and the libuuid client expects a conventional socket path. For a manual test, -p and -s let you isolate the daemon in /tmp instead: the manual itself 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, look 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 with a double fork and hands your shell straight back:

$ 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

• Exit status 0 is the signal that matters. The owner, timestamp and PID file size shown here will vary on your machine.
• -T 30 caps idle time. The daemon exits after 30 seconds of inactivity, which limits a forgotten test process but is not a replacement for stopping it explicitly.

4. Request random UUIDs

Add -d to the test request so the client-side check runs in the foreground. The daemon itself is still the process you started in step 3:

$ 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 for a different bulk request. Do not treat the sample UUIDs above as identifiers that will recur on your host.

Reach for uuidgen instead when you simply need UUIDs for an application or script. These uuidd test options exist to verify communication with the daemon over the socket you chose, nothing more.

5. Request a time-based UUID

Run the equivalent 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 carries a version field of 1, visible as the first hexadecimal digit of its third group. The daemon exists so the UUID library can generate time-based values safely and uniquely when many processes or threads ask for one at once. 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 removal timing vary. If the paths remain, wait briefly and check again. Do not kill a PID copied from a stale file, and if the daemon has already exited because of -T 30, treat the failed kill request as something 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 noted until you have confirmed the matching daemon is gone.

7. Know the options that change the workflow

• -F stops daemonisation. Useful for foreground debugging.
• -P stops the PID file being created. Nothing else changes.
• -S expects systemd to hand over the socket. It implies -F and -P; do not use it in a hand-started shell test. Socket activation needs enabling at build time and is meant for systemd.
• -C turns on continuous clock handling for time-based UUIDs. With no argument it uses a two-hour maximum clock offset; an explicit value is in seconds, or hours or days with h or d, across the documented range of 60 seconds to 365 days. This is a deployment decision, not something to bolt onto a smoke test.