Turning on console blanking on a Linux machine when logged in remotely

November 7, 2020

When my office workstation is running my X session, I lock the screen if it's idle, which blanks the display. However, if the machine winds up idle in text mode, the current Linux kernel defaults keep the display unblanked. Normally this never happens, because I log in and start X immediately after I reboot the machine and then leave it sitting there. However, ongoing world and local events have me working from home and remotely rebooting my office workstation for kernel upgrades and even Fedora version upgrades. When my office workstation reboots, it winds up in the text console and then just sits there, unblanked and displaying boot messages and a text mode login prompt. Even when I come into the office and use it, I now log out afterward (because I know I'm going to remotely reboot it later).

(Before I started writing this entry I thought I had set my machine to deliberately never blank the text mode display, for reasons covered here, but this turned out not to be the case; it's just the current kernel default.)

Leaving modern LCD panels active with more or less static text being displayed is probably not harmful (although maybe not). Still, I feel happier if the machine's LCD panels are actually blanked out in text mode. Fortunately you can do this while logged in remotely, although it is slightly tricky.

As I mentioned yesterday, the kernel's console blanking timeout is reported in /sys/module/kernel/parameters/consoleblank. Unfortunately this sysfs parameter is read-only, and you can't just change the blanking time by writing to it (which would be the most convenient way). Instead you have to use the setterm program, but there are two tricks because of how the setterm program works.

If you just log in remotely and run, say, 'setterm -blank 5', you will get an error message:

# setterm -blank 5
setterm: terminal xterm does not support --blank

The problem is that setterm works not by making kernel calls, but by writing out a character string that will make the kernel's console driver change things appropriately. This means that it needs to be writing to the console and also it needs to be told the correct terminal type so that it can generate the correct escape sequences. To do this we need to run:

TERM=linux setterm -blank 5 >/dev/tty1

The terminal type 'linux' is the type of text consoles. The other type for this is apparently 'con', according to a check that is hard-coded in setterm.c's init_terminal().

(And I lied a bit up there. Setterm actually hard codes the escape sequence for setting the blanking time, so the only thing it uses $TERM for is to decide if it's willing to generate the escape sequence or if it will print an error. See set_blanking() for the escape code generation.)

The process for seeing if blanking is on (or forcing blanking and unblanking) is a bit different, because here setterm actually makes Linux specific ioctl() calls but it does them on its standard input, not its standard output. So we have to do:

TERM=linux setterm -blank </dev/tty1

This will print 0 or 1 depending on if the console isn't currently blanked or is currently blanked. I believe you can substitute any console tty for /dev/tty1 here.

Written on 07 November 2020.
« Console blanking now defaults to off on Linux (and has for a while)
Thinking about two different models of virtualization hosts »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sat Nov 7 21:58:50 2020
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.