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

Bug #869017 reported by Paul Sladen on 2011-10-06
38
This bug affects 5 people
Affects Status Importance Assigned to Milestone
kbd (Debian)
Fix Released
Unknown
kbd (Ubuntu)
Medium
Robie Basak
Zesty
Medium
Robie Basak
linux (Ubuntu)
Undecided
Tim Gardner
Zesty
Undecided
Tim Gardner

Bug Description

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.

Related branches

CVE References

Fabio Marconi (fabiomarconi) wrote :

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

affects: ubuntu → xorg (Ubuntu)

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

Bryce Harrington (bryce) on 2012-02-08
affects: xorg (Ubuntu) → xorg-server (Ubuntu)
Colin Watson (cjwatson) wrote :

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

affects: xorg-server (Ubuntu) → console-setup (Ubuntu)
Colin Watson (cjwatson) on 2012-02-08
Changed in console-setup (Ubuntu):
status: New → Triaged
importance: Undecided → Medium
Changed in console-setup (Ubuntu):
assignee: nobody → Wesley Wiedenmeier (wesley-wiedenmeier)
status: Triaged → In Progress

Disabled blank screen in /etc/kbd/config

affects: console-setup (Ubuntu) → kbd (Ubuntu)

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.]

tags: added: patch
tags: added: wily
tags: added: rls-w-incoming

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

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

Changed in kbd (Ubuntu):
assignee: Wesley Wiedenmeier (wesley-wiedenmeier) → Mathieu Trudel-Lapierre (mathieu-tl)

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) wrote :

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

Changed in kbd (Ubuntu):
status: In Progress → Fix Released

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

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.

Changed in kbd (Ubuntu):
status: Fix Released → Triaged

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) wrote :

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

Changed in kbd (Ubuntu):
assignee: Mathieu Trudel-Lapierre (cyphermox) → Robie Basak (racb)
Changed in kbd (Debian):
status: Unknown → Fix Released
Robie Basak (racb) on 2017-03-22
Changed in linux (Ubuntu):
status: New → Confirmed
Robie Basak (racb) wrote :

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) wrote :

UBUNTU: SAUCE: Disable default console blanking interval

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

Changed in linux (Ubuntu):
assignee: nobody → Tim Gardner (timg-tpi)
status: Confirmed → Fix Committed
Robie Basak (racb) wrote :

Thanks Tim!

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

Changed in kbd (Ubuntu Zesty):
status: Triaged → Invalid
Launchpad Janitor (janitor) wrote :
Download full text (9.0 KiB)

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...

Read more...

Changed in linux (Ubuntu Zesty):
status: Fix Committed → Fix Released
Doug Smythies (dsmythies) wrote :

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

David Rankin (drankinatty) wrote :

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) wrote :

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

atterdag (valdemar-lemche) 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.

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) wrote :

> 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

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Patches

Remote bug watches

Bug watches keep track of this bug in other bug trackers.