Skip to main content
By default the microsandbox agent is PID 1. That’s enough for one-shot processes, but anything that calls into systemctl, loginctl, or expects a session bus will fail. --init auto hands PID 1 over to systemd. The rest of the guest then behaves like a normal Linux box.

​
Use systemd

1

Boot

debian-systemd is one of the optional bases we maintain in guest-images for cases like this. --init auto uses a known init from the image ENTRYPOINT when one is declared, then falls back to probing common distro paths. Image-declared /init wrappers keep their OCI launch contract for attached msb run; bare systemd images still run your trailing command through agentd after boot. See Custom init system for the exact behavior and for pinning to an explicit path.
2

Confirm systemd is PID 1

Or check directly:
3

Manage units

systemctl works as it does on bare metal. Inspect a unit shipped with the image:
Install your own and start it:
The guest detects microsandbox as a container, so packages with policy-rc.d deferral install but don’t auto-start. systemctl enable --now <unit> starts them in one step.

​
Notes

  • Image choice matters. Distroless / minimal images (python:3.13-slim, alpine) don’t ship a systemd init binary. --init auto will fail if it cannot resolve a known image ENTRYPOINT init or find a guest-side probe match. Use a systemd-equipped base or layer one in.
  • Memory budget. systemd’s idle footprint is ~50 MiB; daemons add more. Bump --memory if your service is hungry.
  • Other inits work. --init accepts any absolute path. s6, OpenRC, runit, or a hand-rolled /sbin/init shell script are all fine; auto covers known image ENTRYPOINT inits plus common distro init paths.