How to get fewer ttys with Systemd?

In the old days I just modified /etc/inittab. Now, with systemd, it seems to start tty[1-6] automatically, how should I disable tty[4-6]?

Looks like there’s only one systemd service file, and it use a %I to discern different tty sessions. I hope I don’t need to remove that service, and create each getty@ttyX.service manually.

Asked By: daisy


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 post1:

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 getty@tty2.service, getty@tty5.service 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:


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

Answered By: jasonwryan

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):


In it, it says:

ExecStart=/bin/systemctl --no-block start getty@tty2.service getty@tty3.service getty@tty4.service getty@tty5.service getty@tty6.service

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

Answered By: milli

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

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.

Answered By: temoto

If you’re going to mask as suggested above, make sure to use the right service:

  • If you’ve masked getty@ttyX.service, you’ll notice that switching TTYs with CTRL+ALT+FX will cause TTY to re-spawn.

  • This is because logind spawns getty via autovt@ttyX.service (which links to getty@ttyX.service).

Hence why you’re better off masking autovt@ttyX.service, e.g:

systemctl mask --now autovt@tty2.service


P.S. This solution only blocks logind from spawning TTYs meaning the logic is still active. Consider updating logind.conf to correctly disable VTs as seen above.

Answered By: GrabbenD
Categories: Answers Tags: , ,
Answers are sorted by their score. The answer accepted by the question owner as the best is marked with
at the top-right corner.