Ubuntu server enables screenblanking, concealing crashdumps (DPMS is not used)

[Paul Sladen]

James Rice of Jump Networks noticed that there is a screen-blanker enabled on Ubuntu Server.

James notes that this blanking is not enabling DPMS power saving (thereby negating any power-saving benefit), and is simply turning the screen content blank. This means that the crash output is invisible which is unhelpful on a server (virtual or otherwise).

Ideally the screen should (at a minimum) be turned on and unblanked at the point of an OOPs/crash being printed.

[Fabio Marconi (fabiomarconi)]

Imho only xorg can do a thing like this or is a problem related only to that machine
---
Ubuntu Bug Squad volunteer triager
http://wiki.ubuntu.com/BugSquad

[James A. T. Rice (james-r-ubuntubugs)]

Hi Fabio,

This isn't about xorg - this is about the text mode screen console that the kernel provides.

It seems to be driven by drivers/tty/vt/vt.c , and adding consoleblank=0 kernel parameter disables the behaviour. I'd suggest making that the default for the server edition.

Thanks
James

[Colin Watson (cjwatson)]

We probably ought to handle this in either console-setup or kbd. It has nothing to do with X.

[Wesley Wiedenmeier (wesley-wiedenmeier)]

Disabled blank screen in /etc/kbd/config

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "patch" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

[Wesley Wiedenmeier (wesley-wiedenmeier)]

We should get sign off on this from the ubuntu-devel mailing list before making this change, as it changes behaviour. The new behaviour makes sense, as there does not seem to be an advantage to blanking the screen like this, but there might be some people who object

[Mathieu Trudel-Lapierre (cyphermox)]

I'm looking into this now; will test and sponsor the fix.

[Mathieu Trudel-Lapierre (cyphermox)]

Please also file a bug on the Debian BTS; it's also relevant to Debian although they may have a different opinion on whether or not this should be done.

[Launchpad Janitor (janitor)]

This bug was fixed in the package kbd - 1.15.5-1ubuntu4

---------------
kbd (1.15.5-1ubuntu4) wily; urgency=medium

  * debian/conffiles.d/config: Disable automatic virtual console screen blank
    - Don't blank screen on virtual consoles, because most systems running
      without X are headless and when they are connected to a monitor for
      debugging the screen should not be blank
    - LP: #869017

 -- Wesley Wiedenmeier <email address hidden> Tue, 04 Aug 2015 18:32:04 +0000

[Wesley Wiedenmeier (wesley-wiedenmeier)]

Thank you for sponsoring, I will open a bug report on their tracker and link to this.

[Mathieu Trudel-Lapierre (cyphermox)]

I'm going to revert this change. We've been carrying this is kbd since wily, so it landed in xenial, but it doesn't even work (VT still blanks here, on a newly-installed system). Debian also drops the files, so to support not blanking the console, we'd need to think of some alternate method of, for example, introducing consoleblank=0 on the kernel command-line (via grub-installer/grub2?). Another option might be to convince kernel people to patch the blankinterval value in vt.c in the kernel sources themselves.

I totally understand why people might want this feature (a server crashing is not nice. It shouldn't happen often, but it's already helpful to have the ILO show an error message and not just a blanked screen). I'm just not sure what the best way to handle it would be in light of the changes in kbd (dropping its init script, and the init script not working in the first place).

In the meantime, please consider adding consoleblank=0 in the command line for your systems. You can do this by adding it to /etc/default/grub.

[Mathieu Trudel-Lapierre (cyphermox)]

Tracker bug for the initscript for kbd was https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796583.

Please make sure you link your upstream bug too.

[Robie Basak (racb)]

I'll see if I can drive a better fix for this.

[Robie Basak (racb)]

Kernel team,

This default appears to be set in drivers/tty/vt/vt.c to "10*60". Would you be agreeable in changing the default to 0 for all of Ubuntu in the next release (perhaps Zesty+1)? For example we could patch it, or we could add a parameter to make it configurable (either defaulting to 10*60 or to 0), and we could try to upstream any of this.

For desktop (and "client" generally), it should make no difference as X is always running anyway.

For server, I think it makes sense for the default to always be 0. IMHO, CRT burn in concerns should no longer govern the default case, and affected users could always set consoleblank back in bootloader configuration.

For IoT, in my limited experience it probably doesn't make sense either.

Perhaps even upstream would be willing to consider a change to 0 by default?

If we don't agree to have Ubuntu's kernel do this by default, then I guess we'll need to do it at packaging level to get the parameter in by default. But I thought I'd start with the kernel default side first as it makes sense to me to change it.

[Tim Gardner (timg-tpi)]

UBUNTU: SAUCE: Disable default console blanking interval

I'll also send this upstream to get some opinions.

[Robie Basak (racb)]

Thanks Tim!

Invalid for kbd then I guess, as the fix will be in the kernel.

[Launchpad Janitor (janitor)]

This bug was fixed in the package linux - 4.10.0-15.17

---------------
linux (4.10.0-15.17) zesty; urgency=low

  [ Tim Gardner ]

  * Release Tracking Bug
    - LP: #1675868

  * In ZZ-BML (POWER9):ubuntu17.04 installation Fails (LP: #1675771)
    - powerpc/64s: fix handling of non-synchronous machine checks
    - powerpc/64s: allow machine check handler to set severity and initiator
    - powerpc/64s: POWER9 machine check handler

  * [Feature] R3 mwait support for Knights Mill (LP: #1637550)
    - x86/cpufeature: Enable RING3MWAIT for Knights Landing
    - x86/cpufeature: Enable RING3MWAIT for Knights Mill
    - x86/msr: Add MSR_MISC_FEATURE_ENABLES and RING3MWAIT bit
    - x86/elf: Add HWCAP2 to expose ring 3 MONITOR/MWAIT
    - x86/cpufeature: Add RING3MWAIT to CPU features

  * [Feature] GLK:New device IDs (LP: #1645951)
    - mfd: intel-lpss: Add Intel Gemini Lake PCI IDs
    - pwm: lpss: Add Intel Gemini Lake PCI ID
    - i2c: i801: Add support for Intel Gemini Lake
    - spi: pxa2xx: Add support for Intel Gemini Lake
    - [Config] CONFIG_PINCTRL_GEMINILAKE=m
    - pinctrl: intel: Add Intel Gemini Lake pin controller support

  * Zesty update to v4.10.5 stable release (LP: #1675032)
    - net/mlx5e: Register/unregister vport representors on interface attach/detach
    - net/mlx5e: Do not reduce LRO WQE size when not using build_skb
    - net/mlx5e: Fix broken CQE compression initialization
    - net/mlx5e: Update MPWQE stride size when modifying CQE compress state
    - net/mlx5e: Fix wrong CQE decompression
    - vxlan: correctly validate VXLAN ID against VXLAN_N_VID
    - vti6: return GRE_KEY for vti6
    - vxlan: don't allow overwrite of config src addr
    - ipv4: add missing initialization for flowi4_uid
    - ipv4: mask tos for input route
    - sctp: set sin_port for addr param when checking duplicate address
    - net sched actions: decrement module reference count after table flush.
    - l2tp: avoid use-after-free caused by l2tp_ip_backlog_recv
    - vxlan: lock RCU on TX path
    - geneve: lock RCU on TX path
    - mlxsw: spectrum_router: Avoid potential packets loss
    - net: bridge: allow IPv6 when multicast flood is disabled
    - net: don't call strlen() on the user buffer in packet_bind_spkt()
    - net: net_enable_timestamp() can be called from irq contexts
    - ipv6: orphan skbs in reassembly unit
    - dccp: Unlock sock before calling sk_free()
    - amd-xgbe: Stop the PHY before releasing interrupts
    - amd-xgbe: Be sure to set MDIO modes on device (re)start
    - amd-xgbe: Don't overwrite SFP PHY mod_absent settings
    - bonding: use ETH_MAX_MTU as max mtu
    - strparser: destroy workqueue on module exit
    - tcp: fix various issues for sockets morphing to listen state
    - net: fix socket refcounting in skb_complete_wifi_ack()
    - net: fix socket refcounting in skb_complete_tx_timestamp()
    - net/sched: act_skbmod: remove unneeded rcu_read_unlock in tcf_skbmod_dump
    - dccp: fix use-after-free in dccp_feat_activate_values
    - team: use ETH_MAX_MTU as max mtu
    - vrf: Fix use-after-free in vrf_xmit
    - net/tunnel: set inner protocol in network gro hooks
    - uapi: fix linux/packet_diag.h use...

[Doug Smythies (dsmythies)]

Kernel 4.12-rc1 has this change, so the console now defaults to never going blank. I disagree with this change.

[David Rankin (drankinatty)]

The console should blank and powerdown, with defaults of 10 min (600s) and 12 min, respectively. Servers are NOT headless - that is a boneheaded assumption to justify crippling /sys/module/kernel/parameters/consoleblank to mask other problems that should be fixed instead of swept-under-the-rug by disabling default behavior that is relied upon -- and has worked 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 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.

Fix the problem, don't break default behavior.

[JoseStefan (josestefan)]

So this "fix" seems to cause Kernels released with zesty (and newer) keep the monitor always ON. No blanking, and no power down either.

Before this fix, a clean install of Ubuntu server would signal the monitor to sleep/standby after a short while. Now the default behavior is to leave the monitor always on, wasting power.

While blanking itself should be negligible to power savings and monitor longevity, sleep states are still an important feature.

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1767568

[Valdemar Lemche (atterdag)]

I have to concur that it must this change is really a detriment to people that still use Ubuntu on physical servers - i.e. running OpenStack hosts. Fixing one problem by creating another problem is really poor problem management.

[Robie Basak (racb)]

On Sun, Jul 21, 2019 at 09:59:40PM -0000, atterdag wrote:
> I have to concur that it must this change is really a detriment to
> people that still use Ubuntu on physical servers - i.e. running
> OpenStack hosts. Fixing one problem by creating another problem is
> really poor problem management.

I don't see how we created another problem. We changed the default,
that's all. We thought the new default would be more suitable for more
users. Clearly not everyone will agree with the default - that's the
nature of defaults, and why the behaviour is configurable.

If you think that a different default would be better for Ubuntu, by all
means let's discuss that, as I described by suggesting a venue for that
discussion in the previous comment. But it doesn't follow that a default
not suitable in your particular situation is a problem in general.

If on the other hand the problem you're describing is not a matter of
the default configuration, then please file your own bug with specific
details.

[Robie Basak (racb)]

> as I described by suggesting a venue for that
discussion in the previous comment.

Sorry, I confused bugs. My comment was in a different bug but still relevant: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1767568/comments/37

[linux_joy (linux-joy)]

See https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1767568/comments/33 :
> (..) I have noticed that the /etc/kbd/config is present on 16.04, I believe it was missing on 18.04. (...)

Please, can someone tell me: Why was /etc/kbd/config (and also /etc/kbd/remap) removed on kbd package Version 2.0.4-2ubuntu1 in bionic? If it had been left, the console could still blank and powerdown (DPMS)!

[Charles Wilkins (cg-chas)]

To Robie Basak, specifically #22,

You said, "I don't see how we created another problem. We changed the default,
that's all."

You seem to have concluded that merely a change of default functionally was made at some point.

Perhaps that is the case. If so, what specifically was the default setting that was changed? For example, was it a kernel compilation time option? If so, can you please specify what setting can be changed back in order to re-enable Console blanking using DPMS (console display in power saving mode) for Ubuntu server 18.04?

[Robie Basak (racb)]

Here's the change that was made: https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/zesty/commit/?id=a87ae50beda8c46c543b39e19070549cf355eb65

It's just the default of the consoleblank= kernel parameter. You can override it by specifying that parameter to the kernel at boot time (eg. via /etc/default/grub)

If someone could test and document exact steps to do this override in this bug please, that'd be useful to users and I'd appreciate it.

[Doug Smythies (dsmythies)]

Ever since the default changed to never blanking the screen, and after I whined in comment #18 above, I have been running this in /etc/default/grub:

GRUB_CMDLINE_LINUX_DEFAULT="<other stuff> consoleblank=300 <other stuff>"

always save a copy of grub first, and do "sudo update-grub afterwards", then re-boot.

[Charles Wilkins (cg-chas)]

Some additional information and observations.

What I am currently seeing with this issue on 3 systems running Ubuntu 18.04 that did not occur on the same systems that previously ran 16.04 is that the actual screen blanking in 18.04, aside from default settings or overrides, fails to turn off the monitor using DPMS as it did in 16.04, but only with nvidia binary drivers installed and only in 18.04, and only with the console blanking code in its current state.

In 18.04 without the nvidia binary driver, console blanking seems to work, as expected, with the consoleblank=n. This includes a correct power down.

In 18.04 with the nvidia binary driver 340.107, console blanking only blanks the screen, but fails to power down the monitor- yet a call to vbetool dpms off does work, as do any similar calls in X for those systems that have X installed. So if vbetool dpms works with the nvidia binary driver and the console blanking code no longer does, I am half way to an assumption that the dpms code in the console blanking has changed, with some reservation that possibly the latest nvidia binary driver doesn't like the way the call is coming from the newly changed console blanking code.

This problem did not exist in 16.04, on any of our systems to my knowledge, with or without a graphical desktop installed and with or without a binary driver installed.

From my perspective, this isn't an issue of default blanking behaviour, but rather an issue with a broken dpms call in 18.04 to a system with the nvidia binary driver. Other calls, such as vbetool dpms off work as do those within graphical desktop systems such as those like the one that xscreensaver uses.