What is the reason for having so many virtual consoles?

I would understand if there was one in case the GUI crashes but 6 more besides the default? What are they for? I even see no usage for any of them except when the GUI freezes.

  • I agree with Mateo's answer below. Why not MORE? I find myself having all 6 open and wishing for more (and the GUI often remains "shut off" at the login screen).
    – haziz
    Mar 10 '19 at 0:11

Short answer: why not? (implied smile, please)

More lengthy one: it is mostly a history thing, I suppose. There were 6 virtual consoles configured with getty in the first linux I booted with VC support, I really forgot when (it was around 1990, I think). Then when you started the graphical environment (by hand, with startx) it opened itself on the first free VC, which happened to be #7. And I still did most of my work on VCs at the time: the editors were much faster and sometime I used more VCs than the standard six, and my laptop was not exactly a graphic monster...

For example, I used to run three editors (a program, its input data, a TeX file describing it), one VC for compiling, another to read a manual, and another one connected via telnet to my mail server.

I suspect that the rationale for still using six virtual consoles is to let the graphic VC on #7 for everyone, so you can write on manuals "Ctrl-Alt-F7" and not "Ctrl-Alt-Fx where x is the first free VC".

As a side note, you can (I suppose --- never tried) trim down the VCs. Simply do

sudo bash -c "echo 'manual' >> /etc/init/tty6.override"

to stop VC#6, following the upstart manual.

  • It's possible to trim down number of active tty, but not the device files themselves ( unless people want to recompile kernels ). See my answer below Aug 28 '16 at 16:12

Why not more? Run top or htop in one (gives cpu/memory usages statics), ssh to other systems in 2 or 3, run some automated task in another, keep one free just in case, login to multiple users in a few more, run cmatrix on one, start the GUI in another with -

startx -- :1

(some graphics have bugs with this)


When you really start to utilize this feature 7 tty's (the seventh one is the default)seem way to few - and you can add more.

To reduce the number: How can I reduce the number of TTYs?


All of the /dev/tty* entries are something known as device file, in accordance with Unix philosophy. They serve as a link between user and actual device, but their purpose may differ slightly.

How virtual consoles allocated

Per console(4) manual:

Before kernel version 1.1.54 the number of virtual consoles was compiled into the kernel (in tty.h: #define NR_CONSOLES 8) and could be changed by editing and recompiling. Since version 1.1.54 virtual consoles are created on the fly, as soon as they are needed.

Dynamic creation in pre-systemd systems is controlled via /etc/default/console-setup variable ACTIVE_CONSOLES. From console-setup(5) manual:

ACTIVE_CONSOLES Specifies the device files in /dev of the virtual terminals to be configured. File name wild-cards (*, ?) are allowed. On Linux usually you can set this to /dev/tty[1-6] and on FreeBSD a sensible value is /dev/ttyv[0-8]. You can assign to this variable also the special value guess. It will cause setupcon(1) to attempt to guess the active virtual consoles by looking in configuration files such as /etc/inittab and /etc/ttys. This guessing is not always reliable.

Systemd configuration relies on /etc/systemd/logind.conf variable NAutoVTs. Quote from logind.conf documentation

NAutoVTs= Takes a positive integer. Configures how many virtual terminals (VTs) to allocate by default that, when switched to and are previously unused, "autovt" services are automatically spawned on. These services are instantiated from the template unit autovt@.service for the respective VT TTY name, for example, autovt@tty4.service. By default, autovt@.service is linked to getty@.service. In other words, login prompts are started dynamically as the user switches to unused virtual terminals. Hence, this parameter controls how many login "gettys" are available on the VTs. If a VT is already used by some other subsystem (for example, a graphical login), this kind of activation will not be attempted. Note that the VT configured in ReserveVT= is always subject to this kind of activation, even if it is not one of the VTs configured with the NAutoVTs= directive. Defaults to 6. When set to 0, automatic spawning of "autovt" services is disabled.

Decreasing appropriate variable for your environment and rebooting will help decreasing the number of VTs. Deleting those devices can be done manually via this command:

sudo bash -c 'for num in $(seq 10 63 ) ; do MAKEDEV -v -d "tty$num" ; done'

This , however, is somewhat pointless - the device files do not take up any space and don't influence system performance.

See also https://askubuntu.com/a/27975/295286

Virtual consoles general info

Device files like /dev/tty123 can be used to interact with the system via regular shell.Those are virtual terminals. Ubuntu system is configured to open by default TTY 1 through 6 , but one can manually open more, for example:

sudo openvt -c 9 -s "bash"

That will open bash as root on /dev/tty9 and immediately switch you to that TTY ( if done on local terminal, but if you do so via remote ssh session, in which case you may need to use chvt 9 , where 9 is /dev/tty9 in this example). To do the same without sudo as non-root, you will have to change ownership of tty you want to open. For example,

$ sudo chown admin_user:tty /dev/tty8 
$ openvt -c 8 -l 

That would log me in with my default shell on tty8. In my tests, however, it seems that this works via TTY only, so if you're doing that via terminal emulator, that might not work ( I was getting Couldn't get a file descriptor referring to the console error and only sudo openvt -c 8 -l worked for me from emulator )

From historical standpoint, before all the fancy terminal multiplexers were created, this was a useful feature - you could spawn up to 62 commands ( maybe servers ) on those consoles, and let them run, while working in 63rd. Nowadays, it might not be as necessary.

There are multiple device files created by default. Active ones are 1 through 6, but one can alter their number by editing /etc/default/console-setup, specifically this part:

# Setup these consoles.  Most people do not need to change this.

ttyS* devices

These are device files used for serial consoles , aka UART (also known as RS-232 ). In the past many computer systems would come with serial port. Nowadays, this could mostly be found on server type of computers. Multiple ttyS devices could be useful with RS-232 hubs, which allow connecting multiple devices to be managed via USB or Ethernet.

For electrical engineers (which is what I am majoring in in college) , we use serial port to interact with microcontrollers and development boards ( Arduino , for instance ). Single port computers , such as Raspberry Pi, also use it. Nowadays, the serial connection is established using USB to UART cable, and opening the console in terminal via screen like so:

screen /dev/ttyUSB0 115200 # the number is baud rate or speed

Note , that Arduino and Raspberry will create their own device file for serial connection, /dev/ttyUSB0 or /dev/ttyACM0

vcs* devices

According to man vcs these are console memory devices. In simple words, if you do sudo cat /dev/vcs1 you will see what's on screen in /dev/tty1 , at least up to maximum amount of lines in that terminal.

  • Comments are not for extended discussion; this conversation has been moved to chat.
    – terdon
    Jan 8 '19 at 16:26

The practicality is real. There can be multiple programs running simultaneously in the truly multi-user Linux system, and you can drop in to check on each one if each one runs in its own virtual terminal. When you log in to each one, you can log in as different users, if needed. Now, granted, many folks arrive at Linux with a single-user perspective, but since Linux was born multi-user, that capability was never discarded.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.