How to get fewer ttys with Systemd?

There is no real need to disable "extra" TTYs as under systemd gettys are generated on demand: see man systemd-getty-generator for details. Note that, by default, this automatic spawning is done for the VTs up to VT6 only (to mimic traditonal Linux systems).

As Lennart says in a blog post¹:

In order to make things more efficient login prompts are now started on demand only. As you switch to the VTs the getty service is instantiated to [email protected], [email protected] and so on. Since we don't have to unconditionally start the getty processes anymore this allows us to save a bit of resources, and makes start-up a bit faster.

If you do wish to configure a specific number of gettys, you can, just modify logind.conf with the appropriate entry, in this example 3:

NAutoVTs=3

^{1. In fact the entire series of posts—currently numbering 18— systemd for Administrators, is well worth reading.}

On Debian-based systems, there is a file that causes 5 extra getty's to be launched on startup if you've just built a server (without dbus service):

/lib/systemd/system/getty.target.wants/getty-static.service

In it, it says:

[Service]
Type=oneshot
ExecStart=/bin/systemctl --no-block start [email protected] [email protected] [email protected] [email protected] [email protected]
RemainAfterExit=true

Just deleting this file will stop the extra getty's from spawning. Feel free to shorten the list if you want to just spawn one extra getty (for 2 virt consoles). Note that you automatically get one on tty1 so you always have at least one virtual console.

See also: systemd-logind.service fails to start if dbus is missing

To disable gettys on particular TTYs 4-6 while possibly leaving 1-3 and 7-9 working, run:

for i in {4..6}; do
  systemctl mask getty@tty${i}.service
done

mask creates symlink /etc/systemd/system/{name} -> /dev/null which effectively disables service. Attempt to run it via systemctl start will display error Failed to start NAME.service: Unit NAME.service is masked.

If you have A.service Wants=masked.service, then start A will succeed but also generate dependency start error in journal.

If you have B.service Requires=masked.service, then start B will also fail.

Yup, necroanswer. Cheers.