Commit a Transient Machine ID with systemd-machine-id-commit

systemd-machine-id-commit.service handles one narrow job: making a temporary, memory-backed machine ID permanent. This guide checks whether it has useful work to do, runs it when appropriate, and verifies the result without ever printing the ID. It matches the installed systemd 255.4-1ubuntu8.17 package and its 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 filesystem, while /etc is writable. It runs systemd-machine-id-setup --commit, which 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 unit waits until local-fs.target and first-boot-complete.target. It also 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 filesystem, 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 filesystem source or type. A persistent setup shows the path as an ordinary file belonging to the filesystem containing /etc. The exact source and options are host-specific.

$ 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 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 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 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.