Console upgrade useless.. XSet warnings all over the screen

Bug #883618 reported by MMlosh
This bug affects 6 people
Affects Status Importance Assigned to Milestone
update-manager (Ubuntu)
Fix Released
James Hunt

Bug Description

Console upgrade via do-release-upgrade of kubuntu desktop is a real pain. (from a Virtual Terminal, no X11 running)
Unless you are watching every upgrade's move, there is no way to determine which question got asked.
It gets scrolled away with line this: xset: Unable to open display ""
also the line gets mis-aligned.

I was not aware of the issue and watched >1h the screen filled with those error messages.. While the upgrade process waited for my answer.

Related branches

MMlosh (mmlosh)
tags: added: regression-release
Revision history for this message
Walter Garcia-Fontes (walter-garcia) wrote :

Thanks for reporting this bug and sorry the unattended report. It would be useful if you could attach some logs from the upgrade, if they are still kept in your sytem, as there may be some error involved in the update process. The logs should be at /var/log/dist-upgrade.

affects: update-manager-core (Ubuntu) → update-manager (Ubuntu)
Changed in update-manager (Ubuntu):
status: New → Incomplete
Revision history for this message
MMlosh (mmlosh) wrote :

Allright.. fetching.

Althought I doubt that other than extreme-early error could lead to such annoying and useless behavior
I have a screenshot saved somewhere

Revision history for this message
MMlosh (mmlosh) wrote :

there are quite a lot of files... which ones do you want?

And no, I am not going to publish anything from that system without reading briefly thru.

20110401-2157 20110401-2218 20111014-1920 apt.log history.log main.log xorg_fixup.log
20110401-2205 20111014-1904 apt-clone_system_state.tar.gz apt-term.log lspci.txt screenlog.0

Revision history for this message
MMlosh (mmlosh) wrote :

Sidenote - I don't understand why is apt-term.log protected from reading, while screenlog.0 is not
While screenlog contains mix of apt-term.log, those xrandr errors and the upgrader messages

Attaching 'diff apt-term.log screenlog.0' from the point where the upgrade started
The first line of the attached file is the first line of apt-term.log.
It's cut right after log from (canceled) earlier do-release-upgrade run, nothing is missing.

Changed in update-manager (Ubuntu):
status: Incomplete → New
Revision history for this message
MMlosh (mmlosh) wrote :

Important: This logs are from ARMEL machine (not x86).
Please ignore if you see "armel" or "" in the file.
I got the same problem on x86-based computers.
But I don't remember which one was run from VT instead of X11+uxterm (only the 1st case has the bug visible)

Revision history for this message
Brian Murray (brian-murray) wrote :

I noticed that this bug is tagged regression-release - did this used to work with a previous version of update-manager? Thanks in advance.

Additionally, what is $DISPLAY set to?

Changed in update-manager (Ubuntu):
importance: Undecided → Medium
status: New → Incomplete
Revision history for this message
MMlosh (mmlosh) wrote :

Yes, I believe this used to be allright (do-relase-upgrade did not mess with X11 at all, which is the correct way of behaving from my point of view)

Xset says it 's unable to manipulate display "<emptystring>",
which means DISPLAY=<emptystring> OR DISPLAY not being set at all.

By default DISPLAY is not set on VTs, I haven't touched it.

Changed in update-manager (Ubuntu):
status: Incomplete → New
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in update-manager (Ubuntu):
status: New → Confirmed
Revision history for this message
MarcRandolph (mrand) wrote :

Marking as Triaged and high since this will affect a larger number of users in the 10.04 LTS -> 12.04 LTS transition. superm1 confirmed this is still occuring in 12.04. His bug #933991 has screenshot and logs (it is now marked as dup of this bug).

Changed in update-manager (Ubuntu):
importance: Medium → High
status: Confirmed → Triaged
summary: - Natty Console upgrade useless.. XSet warnings all over the screen
+ Console upgrade useless.. XSet warnings all over the screen
tags: added: rls-mgr-p-tracking
tags: added: dist-upgrade lucid2precise
Changed in update-manager (Ubuntu):
assignee: nobody → Canonical Foundations Team (canonical-foundations)
Revision history for this message
Steve Langasek (vorlon) wrote :

James, can you please have a look at this one?

Changed in update-manager (Ubuntu):
assignee: Canonical Foundations Team (canonical-foundations) → James Hunt (jamesodhunt)
Revision history for this message
James Hunt (jamesodhunt) wrote :

This xset problem is caused by update-manager calling /usr/bin/xdg-screensaver which in turns calls xset.

DistUpgrade/ in update-manager invokes 'xdg-screensaver reset' repeatedly and xdg-screensaver makes a number of calls to xprop and xset. An example of a problematic call to xset by xdg-screensaver:

xset -q | grep 'DPMS is Enabled' > /dev/null 2> /dev/null

If DISPLAY is not set (as will be the case on a VT), 'xset -q' will write the following text to stderr:

xset: unable to open display ""

xdg-screensaver should probably be calling xset like this:

xset -q 2>/dev/null | grep 'DPMS is Enabled' > /dev/null 2> /dev/null

However, the easiest and quickest fix is to have update-manager invoke xdg-screensaver with stdout+stderr redirected to /dev/null.

What is not clear at this stage is what is causing the failing calls to xprop since all the calls made by xdg-screensaver appear to be safe.

Revision history for this message
MMlosh (mmlosh) wrote :

Hey.. there is somewhat like one message per minute, maybe more.

Is xdg-screensaver checking, if the DPMS is enabled every minute??
Hiding such problem is not a good idea.

Revision history for this message
James Hunt (jamesodhunt) wrote :

xdg-screensaver is being called (up to twice a minute) I think to stop any possibility of a screensaver starting. Each time it is called, it checks DPMS.

A better fix than I suggested in #11 would be for update-manager simply not to call xdg-screensaver if DISPLAY is not set.

Revision history for this message
MMlosh (mmlosh) wrote :

Yeah, that would be a little bit better.

but what about this solution: Not calling xdg-screensaver at all
do-release-upgrade is a console application.
Let the GUIs handle the screensaver if necessary. (And perhaps just by telling the screensaver to disable?)

Also: what about upgrades ran over ssh with X11 forwarding enabled?
The queries needlessly consume the (possibly quite limited) bandwidth.

another example: I use ubuntu on pandaboard, which has slow SD card, the upgrade-related IO takes long to finish.
I am glad I know I have to unset "DISPLAY" to prevent the screen from shining quite bringht whole night.


Revision history for this message
MMlosh (mmlosh) wrote :

Because those who want to can run the "while true do xdg-screensaver reset; sleep 20; done" loop manually.

Maybe an extra parameter called "mess with X11" that would default to off?

Colin Watson (cjwatson)
Changed in update-manager (Ubuntu):
status: Triaged → Fix Committed
Revision history for this message
MMlosh (mmlosh) wrote :

Another reason why should the X11 messing thrown out:
Someone might have set his X11 to blank, say, in 20 seconds (ie on open cellphone, not sure if GTA04 runs ubuntu, but it definitely could).
do-release-upgrade would then turn the screen off and on repeatedly.
Which is even worse with OLED displays, needlessly shortening their lives and wasting energy

So if polling is the best you can do, please don't do anything at all.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package update-manager - 1:0.156.8

update-manager (1:0.156.8) precise; urgency=low

  [ Robert Roth ]
  * Update icon name to use FD.o standard (LP: #921310)

  [ Julien Lavergne ]
  * DistUpgrade/DistUpgrade.cfg, DistUpgrade/removal_blacklist.cfg,
   - Add Lubuntu support, and don't upgrade gnome-components which have been
     removed from Lubuntu installation (LP: #945215)

  [ Barry Warsaw ]
  * Improve the warning issued when i8xx graphics hardware is
    detected. (LP: #941172)

  [ Brian Murray ]
  * DistUpgrade/removal_blacklist.cfg:
    - blacklist gnome-session so that users can always login after a failed
      partial upgrade (LP: #946539)

  [ James Hunt ]
  * Only attempt to stop screensaver if DISPLAY set, and throw away
    xdg-screensaver output. (LP: #883618)

  [ Colin Watson ]
  * Use 'from dbus.mainloop.glib import DBusGMainLoop;
    DBusGMainLoop(set_as_default=True)' to set up the main loop, rather than
    importing the deprecated dbus.glib.

  [ Gabor Kelemen ]
  * Fix misplaced parentheses. LP: #952959
 -- Michael Vogt <email address hidden> Tue, 13 Mar 2012 15:29:59 +0100

Changed in update-manager (Ubuntu):
status: Fix Committed → Fix Released
Revision history for this message
Hunter Wall (wtechboy18) wrote :

I experienced this bug on 11.10 -> 12.04 using 1:, and got spammed to heck by this message. Found a decent solution though: did
ps aux | grep "xdg"
and found this:
root 16097 0.0 0.0 1916 440 pts/20 S+ 15:08 0:00 /bin/sh -c while true; do /usr/bin/xdg-screensaver reset; sleep 30; done
in the output. Killed that process, nothing further.
Thought that future users might find this useful.

Revision history for this message
soredz (soren-edzen) wrote :

Thanks a lot Hunter, you tips saved my day:)

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

Duplicates of this bug

Other bug subscribers