Control systemd Console Logins with systemd-getty-generator

You will learn why systemd starts a login prompt on a particular console, how to verify the generated getty unit, and how to turn off automatic getty creation when it does not suit the machine. The examples describe the locally installed systemd 255.4 package. Allow about 15 minutes. You need a shell; checking is normally unprivileged, while changing boot configuration requires root access and a reboot.

1. See which consoles the kernel advertised

systemd-getty-generator is a systemd generator, not a command you normally run with an option. During boot, systemd runs it with generator output directories and it creates the appropriate dependencies there. The generator reads the kernel command line and the environment supplied to it, then chooses a getty for the machine's context.

Start by checking the current kernel command line:

$ tr '\0' ' ' < /proc/cmdline; echo
BOOT_IMAGE=/vmlinuz-6.8.0-139-generic root=UUID=... ro console=ttyS0,115200

A console= entry can cause a serial console to receive both kernel messages and a login prompt. If no serial console is requested, a normal virtual console or a detected virtualiser console may be selected instead. The generator avoids adding a serial getty where the virtual console subsystem already provides one.

Checkpoint: do not infer the result from the presence of console= alone. It is an input to selection, not a guarantee that a usable device or a successful login service exists.

2. Inspect the generated getty units

List the getty units that systemd currently knows about:

$ systemctl list-units --type=service 'getty@*.service' 'serial-getty@*.service' 'console-getty.service' 'container-getty@*.service' --all
  UNIT                           LOAD   ACTIVE   SUB     DESCRIPTION
  [email protected]     loaded active   running Serial Getty on ttyS0

The exact list depends on the host. The main cases are [email protected] for kernel or virtualiser serial consoles, console-getty.service for /dev/console in a container, and [email protected] for additional container pseudo-terminals.

Check one unit in detail when you have its instance name:

$ systemctl status [email protected] --no-pager
$ systemctl show [email protected] -p LoadState -p ActiveState -p SubState -p FragmentPath
LoadState=loaded
ActiveState=active
SubState=running

Do not copy ttyS0 blindly. Substitute the instance named by your host's unit list. A failed unit is usually a device, baud-rate, access, or console-selection problem; the generator itself may have done exactly what it was asked to do.

3. Read the boot log before changing anything

Generators run early, so their useful evidence is in the current boot's journal. Look for generator messages and the resulting service:

$ journalctl -b --no-pager -g 'getty|console'
$ journalctl -b -u [email protected] --no-pager

The first command is a broad search and may include unrelated console messages. The second is more precise once the unit name is known. If the service is missing, compare /proc/cmdline, the detected virtualisation environment, and the unit types listed in step 2. Running the generator by hand is not a faithful simulation of a boot: it depends on systemd's generator directories, credentials, and execution environment.

4. Disable automatic getty generation for a boot

Use the kernel parameter systemd.getty_auto=no when you need a boot with no automatically enabled getty from this generator. This is a boot-loader change, so treat it as service-affecting: keep console or out-of-band access available before applying it.

For a one-off GRUB edit, append the parameter to the Linux command line for that boot, then boot. Do not make it permanent until you have confirmed that the machine remains reachable. After booting, verify the parameter and the absence of generated getty services:

$ tr '\0' ' ' < /proc/cmdline; echo
... systemd.getty_auto=no
$ systemctl list-units --type=service 'serial-getty@*.service' 'console-getty.service' 'container-getty@*.service' --all

With the generator disabled, no service is enabled by this generator. A unit explicitly enabled elsewhere, or a getty started by another mechanism, is outside this switch. To undo the test, remove systemd.getty_auto=no from the boot entry and reboot. If you made the change permanent in the boot-loader configuration, restore the previous configuration through that tool rather than deleting files from /boot by hand.

5. Use the environment control only in the right context

The installed manual also documents SYSTEMD_GETTY_AUTO. It accepts the same optional boolean control and defaults to enabled. This is useful when a systemd-managed generator environment deliberately supplies it; exporting it in an unrelated interactive shell does not retroactively change units already generated during boot.

For additional selected terminals, system credentials named getty.ttys.serial and getty.ttys.container can contain one TTY name per line. They were added in systemd 254. Provision them through the system's credential mechanism, not by editing generated files. A credential entry requests an instance; it does not repair a missing device, replace authentication policy, or make an insecure serial line safe.

Common traps

• Changing a service unit directly: generated units are boot output. A manual edit in a generator directory is temporary and will be replaced. Use the kernel command line, documented credentials, or a systemd drop-in for a real service override.
• Expecting a login on every console: the generator chooses consoles according to the environment. Multiple console= entries and virtualisation can produce a different set from the one you expected.
• Using root for inspection: systemctl, journalctl, and reading /proc/cmdline normally need no elevation. Reserve sudo for the boot-loader or credential-management operation that actually changes system state.
• Disabling the last recovery path: a serial or container console may be your only administrative route. Test a temporary boot change first and keep a working recovery channel.