Bringing up a root filesystem with
systemd-nspawn -b -D and consequently logging into the container necessitates that either a password is set for the desired user, or that an
autologin override is present for the
If a container is brought up with
machinectl start instead, the
console-getty override has no effect for consequent
machinectl login invocations, as
container-getty@.service is in charge of the pseudo terminals that
login attaches to instead.
State: running Jobs: 0 queued Failed: 0 units Since: Sat 2019-03-16 17:11:26 CET; 16min ago CGroup: / ├─init.scope │ └─1 /lib/systemd/systemd └─system.slice ├─console-getty.service │ └─48 /sbin/agetty --noclear --keep-baud console 115200,38400,9600 vt220 └─system-container\x2dgetty.slice └─email@example.com ├─53 /bin/login -f └─58 -bash
systemctl statusoutput of container.
Logging into the container without a password can still be achieved by using the
shell subcommand of
machinectl, though the
login subcommand remains the only option for Linux distributions that ship with older versions of
systemd, which do not include
shell (before v224).
ExecStart override for
container-getty@.service can be used to replicate the behaviour of
systemctl edit container-getty@.service
[Service] ExecStart= ExecStart=-/sbin/agetty --noclear --autologin root --keep-baud pts/%I 115200,38400,9600 $TERM
- The empty space after the first
ExecStartis there on purpose, as it tells
systemdto clear the pre-existing
rootwith another user name will instead enable automatic login for the specified user.
systemdas well as
dbusshould be installed in the container root file-system, otherwise both
shellwill fail (
Failed to get shell PTY: Protocol error).
- The override doesn't necessarily have to be created with the
systemd. Creating and subsequenly populating the contents of
/etc/systemd/system/container-getty@.service.d/override.confalso works just as well.