Route Linux Kernel Messages to a Specific Virtual Console

You will use setlogcons to send kernel messages to a chosen Linux virtual console, then restore the default behaviour. This guide uses the installed kbd package version 2.6.4-2ubuntu2, whose setlogcons reports itself as kbd 2.6.4. Allow about ten minutes, including a console switch to verify the result. You need a local virtual terminal and an account allowed to perform console administration.

This command changes where kernel messages are displayed. It does not change the kernel message level; use dmesg for that separate job. Plan the change before applying it on a machine where an operator depends on a particular console for alerts.

1. Confirm the installed command

Start with read-only checks. These do not need elevated privileges and do not change message routing:

$ command -v setlogcons
/usr/bin/setlogcons
$ setlogcons --version
setlogcons from kbd 2.6.4
$ setlogcons --help
Usage: setlogcons [N]
Send kernel messages to the current console or to console N

The local help confirms the important interface: an optional console number N. The installed manpage describes the same command as setlogcons N. Do not infer a service name, configuration file or persistent boot setting from this tool. It performs one console-routing operation.

2. Identify the virtual console you want

Linux virtual consoles are commonly named tty1, tty2 and so on. The number passed to setlogcons is the console number, so 2 means virtual console tty2. Check the terminal you are using without changing anything:

$ tty
/dev/tty2

Your result will differ. If it is /dev/tty2, use 2 as the target in the next step. A graphical terminal such as a desktop terminal emulator is not itself a Linux virtual console, so do not assume that its window number maps to an N value.

Use an explicit, known console number rather than guessing. The installed program accepts values from 0 through 127. The special value 0 is useful because it means the current console, which is also the default described by the manpage.

3. Route messages to one console

This is the state-changing step. It normally requires elevated privileges because it uses the kernel console interface. Replace 2 with the target console number you identified:

$ sudo setlogcons 2

On success, the command is quiet and returns status 0:

$ sudo setlogcons 2
$ printf 'exit status: %s\n' "$?"
exit status: 0

There is no success message to parse. The useful result is the exit status. Kernel messages are now directed to console 2. This is a runtime setting, not a replacement for configuring the system's boot or logging policy.

4. Generate a controlled test message

Only do this if writing a test message to the kernel log is acceptable on the host. It is not needed merely to apply the setting. The following command is privileged and adds one informational message to the kernel log:

$ sudo dmesg -n 6

The setlogcons(8) manpage specifically points to dmesg for changing the message level. This command therefore tests a related setting, not the destination selected by setlogcons. Use your normal kernel logging and monitoring tools to verify the message path, and remember that rate limiting, log readers and the console's current display can affect what you see.

Do not use a noisy workload as a test. A console flooded with kernel messages can hide an operator prompt and make recovery harder. If your purpose is only to confirm the command accepted the number, the status check in step 3 is the safer verification.

5. Restore the default destination

The documented default is the current console. Restore that behaviour explicitly with console number 0:

$ sudo setlogcons 0
$ printf 'exit status: %s\n' "$?"
exit status: 0

This is the undo operation for the example. Switch back to the console you are actively using and leave it visible long enough to confirm that routine kernel messages are no longer being sent to the earlier test target. If the command reports an error, keep the existing console available and investigate before trying several different numbers.

A failed command does not provide a new destination. Check that you are using a real Linux virtual console, that the number is within the accepted range, and that your account has the required privilege. For example, an out-of-range value is rejected before the routing ioctl is attempted:

$ setlogcons 999
setlogcons: Argument is too big: 999
$ printf 'exit status: %s\n' "$?"
exit status: 65

The exact diagnostic prefix can vary with localisation, but the useful clues are the rejected argument and the non-zero status. Do not treat a rejected number as proof that the target console exists or is usable.

6. Keep the boundaries clear

setlogcons selects the console receiving kernel messages. It does not select a systemd journal output, move existing log entries, set the kernel's severity threshold, or make the choice persistent across reboot. If you need persistent logging, configure the host's logging service separately. If you need fewer messages, change the kernel message level through the appropriate dmesg operation after checking that host's policy.

Do not run the command from an automated service merely because its output is missing from a terminal. A service may have no meaningful virtual console, and redirecting messages can make incident response less predictable. For remote administration, use the provider's documented console access and keep a tested recovery path before changing routing.

The upstream kbd implementation also contains newer option forms such as an explicit console device selector, but the installed command's help on this machine presents only [N]. For portable instructions against this installation, use the positional console number documented by the local manpage. Check setlogcons --help after an upgrade before relying on extra options.