Bug 1094452

It's the intended behavior introduced by the commit
    a4199f5eb8096d63828f7333fa45650a7b0a99ed

    tty: Disable default console blanking interval

    BugLink: http://bugs.launchpad.net/bugs/869017
    
    Console blanking is not enabling DPMS power saving (thereby negating any
    power-saving benefit), and is simply turning the screen content blank. This
    means that any crash output is invisible which is unhelpful on a server
    (virtual or otherwise).
    
    Furthermore, CRT burn in concerns should no longer govern the default case.
    Affected users could always set consoleblank on the kernel command line.

This is not the intended behavior because it breaks console blanking for every server operating without X. All monitors on my server are stuck ON 24/7 because default console blanking is broken.

The intended behavior is to have consoleblank default to 600, so that console blanking works correctly. This has worked properly for nearly 20 years. There is no reason to break the default behavior by zeroing consoleblank. 

The underlying issue is apparently a problem with the vt blanking effecting the new X. So instead of fixing X properly to work with default consoleblank, all default console blanking was broken by setting the value to 0 as a workaround to an X problem.

Let's fix the problem so that default console blanking works correctly, as it always has, instead of just giving up and disabling console DPMS altogether.

Could you (or anyone who wants to change) rather argue this to upstream?  At best post a trivial patch to revert that.

There is no reason to "fix" this *only* in our side, if the suggestion is absolutely right.

In principle, we usually follow the upstream policy.  So the right way to correct such behavior is to change the upstream at first.  Thanks.

The console should blank and powerdown, with defaults of 10 min (600s) and 12 min, respectively. Servers are NOT headless as used to justify the change in the "intended behavior" link - that is a boneheaded assumption to justify crippling /sys/module/kernel/parameters/consoleblank to mask other problems that should have been fixed instead of swept-under-the-rug by disabling default console blanking and powerdown -- that has worked flawlessly for the past 15 years.

What kind of defect in reasoning makes it OK to break default behavior? None. If there is a problem with X due to some change in X or vt reordering that now makes blanking /dev/tty0 a problem for X users -- then fix X, don't break default vt blanking and powerdown.

The type of backwards reasoning in https://bugs.launchpad.net/ubuntu/+source/kbd/+bug/869017?comments=all that suggests breaking defaults instead of fixing the actual problem is what leads to a proliferation of unnecessary kernel parameters passed at boot or forces the creation of unnecessary startup services just to restore basic default terminal blanking and powerdown. That strikes me as completely unacceptable and a complete abdication to insure simple default features -- just work. 

I don't mean to beat a dead horse, but fix the problem, don't break default behavior. This type of fundamental behavior by the console should just work as it always has, not be something users now have jump through hoops adding startup files or passing kernel parameters just to restore simple, basic, default power-saving features.

You need to argue this with upstream devs.

In anyway, I leave this to Jiri, who was on Cc in the affecting commit.

If I ask in the server world, i.e. linux machines running without X: "How many of them have monitor connected?"

What would you answer?

1) minority? Yes, this is the right answer, so the default was changed respecting the majority.
2) other answer? Think about it more and jump to 1).

It really helps if you have a hanged box to come to it, plug in monitor and see the actual crash (the console is not blanked).

If you belong to the minority, you still have the opportunity to change it via the parameter. So what's up?

(In reply to Jiri Slaby from comment #7)
> If I ask in the server world, i.e. linux machines running without X: "How
> many of them have monitor connected?"
> 
> What would you answer?

In my case, I run a datacentre downstairs with 10 19" racks, maybe about 100+ physical servers. The answer is most of them, via KVM switches.  Only 3 monitors. 

> 1) minority? Yes, this is the right answer, so the default was changed
> respecting the majority.
> 2) other answer? Think about it more and jump to 1).

Jiri, I don't see how "most servers do not have a physical console" should affect the default power saving for those that do ??  It's non-sensical. 

> It really helps if you have a hanged box to come to it, plug in monitor and
> see the actual crash (the console is not blanked).

That I can sort of understand. 

> If you belong to the minority, you still have the opportunity to change it
> via the parameter. So what's up?

Just reporting a problem or a change, as I see it.