SYSTEMD-RUN-GENERATOR(8)

💖 SYSTEMD-RUN-GENERATOR 💖

okay bestie, gather round, because this one is a generator — and no, not the AI kind, the systemd kind. The manual name is systemd-run-generator, and it's the little guy that takes stuff you typed on the kernel command line and turns it into an actual system service. iconic behaviour, honestly.

---

✨ NAME ✨

systemd-run-generator — a generator that runs commands you specified on the kernel command line as a system service. like, you whisper it at boot and it becomes a unit. slay.

---

🌸 SYNOPSIS 🌸

/usr/lib/systemd/system-generators/systemd-run-generator

that's it. that's the whole vibe. no flags, no args, it just exists at that path and does its thing.

---

🦋 DESCRIPTION 🦋

so systemd-run-generator is a generator (yes, it implements systemd.generator(7), we'll get there) that reads the kernel command line, and it understands three options. three. a tiny little menu. let's go.

• systemd.run= — if you set this and follow it with a command line, a unit named kernel-command-line.service gets generated for it and the system boots into it. the service has Type=oneshot set, and by default it comes with SuccessAction=exit and FailureAction=exit configured, which means the system is shut down as soon as the command finishes. bye bestie, job done, door closes behind you. 💅

The exit status of the command line is propagated to the invoking container manager, if that applies — and that manager might propagate it even further, all the way to the calling shell. systemd-nspawn(1) is the example that does this, so like, chain of custody for your exit code, fr fr.

If you use this option multiple times, the unit file will contain multiple ExecStart= lines, so all the commands execute in order. one after another, no cutting in line.

The command is started as a regular service, i.e. with DefaultDependencies= on. no special treatment, just a normal service doing normal service things.

• systemd.run_success_action= and systemd.run_failure_action= — use these to tweak how the system reacts to the process completing. in particular, assigning "none" will leave the system running after the command completes (so like, it doesn't immediately dip). for further details on supported arguments, go read systemd.unit(5). 📖

---

🎀 EXAMPLE 🎀

want to add a user to the user database inside a container run with systemd-nspawn(1)? use a command like this:

# systemd-nspawn -D mycontainer -b systemd.run='"adduser test"'

(and yes, the double quoting in that command line is required, bestie. let me break it down because this is the part everyone gets wrong:

• the first level of quoting ('') is processed and removed by the command shell used to invoke systemd-nspawn.
• the second level of quoting ("") is propagated to the kernel command line of the container, and then processed and removed by systemd-run-generator.
• both levels together make sure both words of the specified command line adduser test end up in the generated unit file together, and are neither split apart by the command shell nor by the generator. 🫶

so it's not extra, it's load-bearing. respect the quotes.)

---

👑 SEE ALSO 👑

• systemd(1)
• systemctl(1)
• kernel-command-line(7)
• systemd-nspawn(1)
• systemd.unit(5)
• systemd.service(5)

---

⚠️ quick vibe check: this page is systemd 262.1 energy, and that's the version tag living at the bottom of the original, so I'm putting it here instead. 🌈

and that's the whole page, no cap. go forth and systemd.run= responsibly. mwah. 💖✨🎀🦋🌸💅