Keep systemd's Random Seed Service Safe on Boot and Shutdown

Clone a golden image without clearing the file systemd-random-seed.service writes and every copy boots with identical entropy. This guide checks what the service is doing, locates its persistent seed without exposing its contents, and helps you make a safe decision about OS images. Allow about fifteen minutes. You need a systemd host and an account that can read unit state; only the image-clean-up example needs root.

The examples below describe the locally installed systemd 255.4-1ubuntu8.17 package. The service name and seed path are stable concepts, but unit dependencies and helper details can vary between distributions, so check your own installed files before scripting around them.

1. Check the unit without changing it

Start with read-only status commands. They do not load a seed, write the seed file or restart anything:

$ systemctl is-enabled systemd-random-seed.service
static
$ systemctl is-active systemd-random-seed.service
active
$ systemctl show systemd-random-seed.service -p LoadState -p ActiveState -p SubState -p Result -p ExecMainStatus
LoadState=loaded
ActiveState=active
SubState=exited
Result=success
ExecMainStatus=0

static is expected here. The unit is pulled into the boot transaction by dependencies rather than enabled with a normal preset. Because it is a oneshot service with RemainAfterExit=yes, active (exited) means its boot action completed; it does not mean a long-running daemon is waiting in the background.

Checkpoint: if is-active reports inactive or failed, save the exact output before trying to repair anything:

$ systemctl status --no-pager systemd-random-seed.service
$ journalctl -b -u systemd-random-seed.service --no-pager

These commands normally need no elevated privileges, although journal access may be limited by the host's policy.

2. Inspect the unit's actual boot and shutdown actions

Read the installed unit rather than assuming that a service name is an executable command:

$ systemctl cat systemd-random-seed.service
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/lib/systemd/systemd-random-seed load
ExecStop=/usr/lib/systemd/systemd-random-seed save

On this machine the unit also avoids containers, requires the mount containing /var/lib/systemd/random-seed, runs after the file systems are remounted, and is ordered before shutdown. Its start action is the load operation. Its stop action is the save operation.

The helper has two relevant commands:

$ /usr/lib/systemd/systemd-random-seed --help
systemd-random-seed [OPTIONS...] COMMAND

Commands:
  load                Load a random seed saved on disk into the kernel entropy pool
  save                Save a new random seed on disk

Do not run load or save casually while diagnosing a live system. Both are state-changing operations. Let systemd manage them unless you have a specific recovery procedure and understand the ordering consequences.

3. Verify the seed file without reading its secret bytes

The persistent file is /var/lib/systemd/random-seed. Inspect its metadata, permissions and size rather than dumping it to a terminal or copying it into a ticket:

$ stat -c 'mode=%a owner=%U group=%G size=%s path=%n' /var/lib/systemd/random-seed
mode=600 owner=root group=root size=32 path=/var/lib/systemd/random-seed

The local file is readable and writable only by root, and is 32 bytes. Do not treat those values as a universal contract for every release. The useful safety checks are that the path exists, its owner is appropriate for the host, and its mode does not expose seed material to ordinary users.

If the file is absent, that is not automatically a fault. A first boot or an unpopulated /var hierarchy may not have a saved seed yet. The unit can create state as part of its normal operation, provided the mount is writable and the service is allowed to run.

4. Understand the entropy boundary

Loading a seed helps initialise the kernel entropy pool, but this service normally runs relatively late in early boot, after the initrd and after /var is mounted. It cannot guarantee that entropy was available to programs which ran earlier. The unit also waits synchronously for the kernel random pool to become fully initialised before its start action completes, so an entropy-starved machine can appear to pause here.

That wait can be useful. A service which must not use an uninitialised pool can order itself after systemd-random-seed.service. Do not use this unit as a substitute for earlier entropy sources. On supported systems, systemd documents boot-loader random seeds and virtualised RNG hardware as earlier mechanisms.

Checkpoint: distinguish a slow but meaningful wait from a generic service failure. Compare the unit's journal with the system's boot timing:

$ systemctl show systemd-random-seed.service -p ActiveState -p SubState -p Result -p ExecMainStatus
$ journalctl -b -u systemd-random-seed.service --no-pager

A successful result does not prove that every application received high-quality randomness at its earliest possible moment.

5. Set the crediting policy deliberately

By default, loading the file does not credit entropy to the kernel. This conservative default matters for cloned images: if many machines receive the same seed file, crediting that identical data could make their early random streams similar or guessable.

The service recognises the SYSTEMD_RANDOM_SEED_CREDIT environment setting. A true value enables crediting only when the seed and system state pass superficial consistency checks. The special value force credits entropy whenever the seed file exists. Do not set either value merely to hide a slow boot. It is a security decision for an image or deployment process.

If you need this setting, inspect how your distribution supplies the unit and add a narrowly scoped systemd drop-in rather than editing /usr/lib/systemd/system/systemd-random-seed.service. After changing a drop-in, run sudo systemctl daemon-reload, then verify the effective environment with:

$ systemctl show systemd-random-seed.service -p Environment
Environment=...

The ellipsis is a reminder that the output is host-specific. Keep a record of the policy and its reason. To undo the setting, remove the drop-in, run sudo systemctl daemon-reload, and reboot or otherwise allow the normal boot transaction to run again.

6. Clean a replicated image before first boot

Never bake a live machine's random seed into a golden image that will be copied to multiple systems. Removing it changes persistent state, so do this only while the image is offline or mounted as a staging tree, with a verified backup and a clear rollback plan.

# Run against the mounted image tree, not the running host.
$ sudo rm -- /mnt/image/var/lib/systemd/random-seed
$ test ! -e /mnt/image/var/lib/systemd/random-seed && echo 'seed removed'

Replace /mnt/image with the explicit mount point of the image you are preparing. Do not paste this command against /var/lib/systemd/random-seed on a production host. If you removed the wrong file, stop rather than regenerating it by hand; restore the verified backup or let the intended machine recreate its own state through normal systemd operation.

If the image uses systemd-boot, inspect the EFI System Partition as well. The official image-building guidance also calls for removing its /loader/random-seed before replication. The two locations serve different boot stages, so deleting only the file under /var may leave shared seed material elsewhere.

Common traps

• Calling the helper directly: systemd-random-seed may not be in an ordinary user's PATH. The installed helper is /usr/lib/systemd/systemd-random-seed, and the service supplies its command and ordering.
• Expecting enabled state: static from systemctl is-enabled is not a failure for this unit.
• Reading the seed: a random seed is sensitive state. Check metadata, not contents, and do not put it in logs or diagnostics.
• Using force on clones: that can turn a copied seed into credited entropy. Remove image-specific seed files first and document why crediting is safe.
• Assuming this fixes all early boot randomness: the service runs after the initrd in the usual arrangement. It is a synchronisation point and a persistence mechanism, not the whole early-boot entropy design.