Commit a Transient Machine ID with systemd

You will learn how to check whether systemd-machine-id-commit.service has useful work to do, run it when a transient machine ID can be made permanent, and verify the result without printing the ID. This guide matches the installed systemd 255.4-1ubuntu8.17 package and its systemd 255 manpages.

Allow about ten minutes. You need a shell and access to the system manager. Reading the unit and checking mounts is normally unprivileged. Starting the service needs elevated privileges and can change the machine ID storage mount, so do not run that step on a production host without understanding why the ID is transient.

1. Understand what the service commits

The service is an early-boot, one-shot helper for a narrow situation: /etc/machine-id is mounted separately, usually from a memory file system, while /etc is writable. It runs systemd-machine-id-setup --commit. That command writes the current transient ID to disk and unmounts the separate /etc/machine-id mount in a race-free way.

This is not a general machine-ID generator or reset command. A normal, persistent /etc/machine-id does not need this service. The service unit also waits until local-fs.target and first-boot-complete.target, and it has conditions for a writable /etc and a mount point at /etc/machine-id.

2. Inspect the installed unit

Start with read-only inspection. These commands do not start or reload anything:

$ systemctl cat systemd-machine-id-commit.service
$ systemctl show systemd-machine-id-commit.service \
    -p UnitFileState -p ActiveState -p SubState -p ConditionResult --no-pager

On systemd 255, the unit is a static oneshot service with RemainAfterExit=yes. Static means it is normally pulled in by other units or boot ordering rather than enabled with systemctl enable. Do not try to enable it as a first diagnostic step.

Look for the conditions in the unit output: ConditionPathIsReadWrite=/etc and ConditionPathIsMountPoint=/etc/machine-id. A failed condition is a useful explanation, not necessarily a service fault. On this host, for example, /etc/machine-id is an ordinary file on the root file system, so the mount-point condition is not met.

3. Check the mount without revealing the ID

Use findmnt to check the path and stat to distinguish a regular file from a mount point:

$ findmnt --target /etc/machine-id -o TARGET,SOURCE,FSTYPE,OPTIONS
$ stat -c '%n %F %a %s bytes' /etc/machine-id

A transient setup normally shows /etc/machine-id as its own mount, often with a memory file system source or type. A persistent setup shows the path as an ordinary file belonging to the file system containing /etc. The exact source and options are host-specific.

The machine ID is a stable host identifier and should be treated as confidential. Do not use cat /etc/machine-id in a support transcript, log, screenshot or network command. If you need to check the format without disclosing the value, test it locally:

$ awk 'NR == 1 && $0 ~ /^[0-9a-f]{32}$/ { ok = 1 } END { exit ok ? 0 : 1 }' /etc/machine-id
$ printf 'machine-id format is valid: %s\n' "$?"

The first command produces no output. A status of zero means the first line is 32 lower-case hexadecimal characters. It does not prove that the ID is unique or that it is the ID systemd is currently using.

4. Commit only when the conditions are right

If the preceding checks show a separate mount, confirm that /etc is writable before changing state:

$ test -w /etc && echo '/etc is writable' || echo '/etc is not writable'
$ systemctl show systemd-machine-id-commit.service \
    -p ConditionResult -p ExecMainStatus --no-pager

When you have confirmed the reason for the transient mount, start the unit with sudo:

$ sudo systemctl start systemd-machine-id-commit.service
$ systemctl status systemd-machine-id-commit.service --no-pager

A successful run normally leaves the one-shot unit active with a completed main process. If a condition is false, systemd skips the start and reports that the condition was not met. If the start fails, keep the diagnostic output and inspect the journal before retrying:

$ journalctl -u systemd-machine-id-commit.service -b --no-pager

5. Verify the resulting storage

After a successful commit, check that the separate mount is gone and that the path is still a valid local file:

$ findmnt --target /etc/machine-id -o TARGET,SOURCE,FSTYPE,OPTIONS
$ stat -c '%n %F %a %s bytes' /etc/machine-id
$ awk 'NR == 1 && $0 ~ /^[0-9a-f]{32}$/ { ok = 1 } END { exit ok ? 0 : 1 }' /etc/machine-id
$ echo "format check status: $?"

Do not assume that a successful service start means every application has refreshed its view immediately. The service is designed to keep the file valid and accessible during the unmount, but applications that cache an ID may need their own documented restart or reload procedure. Do not restart unrelated services merely as a precaution.

Common traps

• Trying to enable the unit: it is static and condition-driven. Inspect why it was or was not pulled in instead.
• Using systemd-machine-id-setup without --commit: that is an initialisation operation for a missing or empty file, not the transient-mount commit path described here.
• Changing a read-only system: the commit command intentionally does nothing when /etc is read-only. Repair the mount arrangement through the normal boot configuration.
• Publishing the value: the ID identifies the host. Verify its shape locally and keep the value out of tickets, shell history and telemetry.