SYSTEMD-RA...D.SERVICE(8)

✨ systemd-random-seed.service ✨

okay bestie, welcome to the systemd-random-seed.service page — aka the manual for systemd-random-seed, the little guy whose whole job is Load and save the OS system random seed at boot and shutdown. it's giving entropy delivery service, no cap 💅

---

🎀 SYNOPSIS 🎀

systemd-random-seed.service

/usr/lib/systemd/systemd-random-seed

---

🌸 DESCRIPTION 🌸

so like, systemd-random-seed.service is a service that loads an on-disk random seed into the kernel entropy pool during boot and then saves it at shutdown. peek random(4) for the deets.

by default, no entropy is credited when the random seed gets written into the kernel entropy pool, but you can change that with $SYSTEMD_RANDOM_SEED_CREDIT — more on that below 👇. on disk, the random seed lives in /var/lib/systemd/random-seed.

not me being the bearer of bad news but… this service runs relatively late during the early boot phase. like, generally after the initrd phase has finished and the /var/ file system has been mounted. and so many system services need entropy wayyy earlier than that — which means this service is of limited use for complex systems 😭

the recommended glow-up? use a boot loader that can pass an initial random seed to the kernel, so entropy is available from earliest boot on. for example systemd-boot(7), with its bootctl random-seed functionality. iconic behavior fr fr 🦋

---

okay now the part that's actually kind of slay: when loading the random seed from disk, the file is immediately updated with a new seed retrieved from the kernel, so that no two boots ever operate with the same random seed. main character anti-repetition energy ✨

this new seed is retrieved synchronously from the kernel, which means the service will not complete start-up until the random pool is fully initialized. on entropy-starved systems this may take a while 🙈. the whole point of this functionality is to be used as a synchronization point for ordering services that require an initialized entropy pool to function securely — i.e. services that access /dev/urandom without any further precautions.

---

⚠️ the OS-image replication tea ⚠️

care should be taken when creating OS images that are replicated to multiple systems. if the random seed file is included unmodified, each system will initialize its entropy pool with the same data, and thus — if otherwise entropy-starved — generate the same or at least guessable random seed streams 💀

as a safety precaution, crediting entropy is thus disabled by default.

it is recommended to remove the random seed from OS images intended for replication on multiple systems, in which case it is safe to enable entropy crediting (see below 👇). also see Safely Building Images[1].

see Random Seeds[2] for further information.

---

💖 ENVIRONMENT 💖

• $SYSTEMD_RANDOM_SEED_CREDIT — by default, systemd-random-seed.service does not credit any entropy when loading the random seed. with this option that behaviour may be changed: it either takes a boolean parameter or the special string "force". defaults to false, in which case no entropy is credited. if true, entropy is credited if the random seed file and system state pass various superficial consistency checks. if set to "force", entropy is credited regardless of these checks, as long as the random seed file exists 🔥

added in version 243.

---

👑 SEE ALSO 👑

systemd(1), random(4), systemd-boot(7), systemd-stub(7), bootctl(1), systemd-boot-random-seed.service(8)

---

🍓 NOTES 🍓

1. Safely Building Images https://systemd.io/BUILDING_IMAGES
2. Random Seeds https://systemd.io/RANDOM_SEEDS

---

and that's the whole page bestie, you ate that 🫶 this was the systemd-random-seed.service manual, straight out of systemd 262.1 — go forth and seed responsibly, mwah 💜🌈⭐