83

I'm running linux clusters, mostly on SLES10. The servers are mostly blades, accessed via remote console. There is a real console in the server room, but switched off.

I would like to disable the screen blanking as it serves no purpose and is a nuisance. You have to press key to see if you are connected which is a pain. We are running in runlevel 3, so the console is in text mode, no X11 involved.

Improve this question
2

10 Answers 10

Reset to default
96

You can verify what timeout the kernel uses for virtual console blanking via:

$ cat /sys/module/kernel/parameters/consoleblank
600

This file is read-only and the timeout is specified in seconds. The current default seems to be 10 minutes.

You can change that value with entering the following command on a virtual console (if you are inside an xterm you have to change to a virtual console via hitting e.g. Ctrl+Alt+F1).

$ setterm -blank VALUE

Where the new VALUE is specified in minutes. A value of 0 disables blanking:

$ cat /sys/module/kernel/parameters/consoleblank
600
$ setterm -blank 0
$ cat /sys/module/kernel/parameters/consoleblank
0

setterm has other powersaving related options, the most useful combination seems to be:

$ setterm -blank 0 -powersave off

Thus to permanently/automatically disable virtual console blanking on startup you can either:

  1. add the consoleblank=0 kernel parameter to the kernel command line (i.e. edit and update your boot loader configuration)

  2. add the setterm -blank 0 command to an rc-local or equivalent startup script

  3. add the setterm output to /etc/issue since /etc/issue is output on every virtual console:

    # setterm -blank 0 >> /etc/issue

Choose one alternative from the above.

Improve this answer
8
  • 2
    PS: On a Ubuntu 11.10 system (Thinkpad X200) I noticed a bug where the console blanking by the kernel interferes with a running X11 session. That means that exactly 10 minutes after the last key press the X11 display blanks and you have to cycle to a virtual console to get the X11 screen back (very annoying during e.g. video playback). This is independent of DPMS/screensaver related settings under X11 (think xset etc.). Thus, disabling the virutal console blanking like described above is a quick workaround for affected systems.
    – maxschlepzig
    Feb 18, 2012 at 21:13
  • 2
    On RHEL 5 and 6, I found that putting /bin/setterm -blank 0 -powerdown 0 -powersave off in /etc/rc.local would work great. On RHEL 7, however it would fail. Adding consoleblank=0 to te kernel parameters works on that platform.
    – David C.
    Nov 24, 2015 at 17:07
  • 7
    Please note that you don't actually have to run setterm in a virtual console. You may as well redirect it to it: setterm -blank 0 > /dev/tty1 works just fine. Or you may use setterm -blank < /dev/tty1 to query the current value from tty1 or setterm -blank force < /dev/tty1 to force blanking.
    – Alexander Amelkin
    Nov 9, 2016 at 7:14
  • 1
    might be tty2 then, redhat erm... wizards chose to stick X onto tty1 now
    – Michael Shigorin
    Sep 27, 2018 at 13:57
  • 1
    While I don’t have GRUB, I have a text file on a special partition, called /boot/cmdline.txt. I’ve added another parameter consoleblank=0 to that file. It worked. Thanks a lot!
    – Soonts
    Aug 24, 2022 at 20:52
16

Try using this:

setterm -blank
Improve this answer
9
  • 1
    @markus_b: So add this command to an init script (something like /etc/init/markus-console.conf if you use Upstart, or /etc/init.d/markus-console.sh plus symlinks in /etc/rd?.d for SysVinit, I don't know the actual SuSE locations).
    – Gilles 'SO- stop being evil'
    Feb 25, 2011 at 0:35
  • 2
    @mattdm, not true - systemd usually comes with a rc-local compatibility service - or you can easily add custom services ...
    – maxschlepzig
    Feb 18, 2012 at 12:46
  • 3
    @mattdm Why wouldn't you be able to just write a unit that runs that command?
    – remmy
    Mar 4, 2013 at 12:39
  • 1
    TIP: Exit tmux first, or this won't work.
    – Cody Hess
    Aug 5, 2014 at 1:48
  • 1
    Here's how to install this on a systemd-based distribution, using an rc-local service.
    – basic6
    May 4, 2015 at 15:59
15

According to : https://wiki.archlinux.org/index.php/Display_Power_Management_Signaling#DPMS_Interaction_in_a_console_with_setterm

Prevent screen from turning off (in console)

$ setterm -blank 0 -powerdown 0

Alternatively you can disable console blanking permanently using the following command:

# echo -ne "\033[9;0]" >> /etc/issue

Improve this answer
1
  • 3
    second solution works like a charm on Marvell ARM Debian. All other solutions do nothing.
    – Alexey Sviridov
    Oct 22, 2012 at 12:04
15

The only permanent solution is to add consoleblank=0 to the kernel command-line. You can view the value (which defaults to 600 seconds) in: 

/sys/module/kernel/parameters/consoleblank

(note that the file is read-only). The only way to change the value of consoleblank is to reboot with the new kernel command-line option.

Improve this answer
4
  • 3
    The last sentence is wrong - you don't need to reboot to change the value of consoleblank. See my answer.
    – maxschlepzig
    Feb 18, 2012 at 13:10
  • I have not found setterm -blank to work reliably. It sometimes seems to get reset after logout or switching to other virtual terminals.
    – amcnabb
    Mar 13, 2012 at 18:10
  • To add this permanent setting with grub, edit /boot/grub/grub.conf and append consoleblank=0 to the lines starting with "kernel /boot/vmlinuz...". Then reboot.
    – Hoylen
    Jul 3, 2014 at 4:00
  • 1
    "only" seems like a string word here...
    – notlesh
    Jan 15, 2016 at 19:08
13

I've implemented and tested the following configuration, which works fine on sles10, my workhorse at the moment.

In

/etc/init.d/boot.local

add

setterm -blank

it looks like that is all it takes. Thanks for Uku Loskit and Gilles for the push in the right direction.

Improve this answer
3
  • 1
    I have edited your Answer mercilessly, so don't hesitate to rollback if you don't like it. Also, please Accept your answer because it's the actual solution. You should not Accept an Answer just because you are grateful it led you to the actual answer, if there is actually a better Answer.
    – tshepang
    Mar 1, 2011 at 5:39
  • Sorry, like the original version better.
    – markus_b
    Mar 2, 2011 at 19:07
  • I had to add the top voted answers -powersave off as the ipmi on my systemboard got stupid if it didn't have both parts of this. sadily enough it doesen't keep settings between uses and when these features kick in the window pops to the foreground and starts cycling the window through about 4 different sizes once every second or 2 making it near impossible to catch the window and manually resize it/kick the term out of power save :(
    – Kendrick
    Aug 10, 2015 at 14:36
7

I was really buffled by this problem. All tricks above with using setterm and redirect from/to /dev/tty0 didn't worked from my ssh.

Then I realized a way to disable it:

TERM=linux setterm -blank 0 -powerdown 0  -powersave off >/dev/tty0 </dev/tty0

TERM=linux replaces default TERM (which is xterm-256color on my machine), and helps setterm to query proper parameters from tty0.

You can check result by

cat /sys/module/kernel/parameters/consoleblank

It should be 0. If it is 600, trick hasn't worked out.

Improve this answer
6

If you only want to prevent screen blank out after user login, then just need to append setterm -powersave off -blank 0 to $HOME/.bash_profile of respective users.

Improve this answer
4

/usr/bin/setterm -powerdown 0 might help also

Improve this answer
2

For those of us running Ubuntu 20.04, simply append the following code to /etc/init.d/console-setup.sh

# Set screen blank time to 5 minutes (5)
log_action_begin_msg "Setting screen blank interval to 5 minutes"
/usr/bin/setterm -blank 5
log_action_end_msg $?
Improve this answer
0

This one seems to do the trick:

echo 0 > /sys/class/graphics/fb0/blank

Found on Armadeus wiki.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .