Console upgrade useless.. XSet warnings all over the screen

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.

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

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

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.

Important: This logs are from ARMEL machine (not x86).
Please ignore if you see "armel" or "ports.ubuntu.com" 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)

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?

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.

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

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

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

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

DistUpgrade/DistUpgradeQuirks.py 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.

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.

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.

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.

Thanks

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?

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.

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,
    UpdateManager/Core/utils.py,
    AutoUpgradeTester/profile/lubuntu/DistUpgrade.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

I experienced this bug on 11.10 -> 12.04 using 1:0.152.25.9, 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.

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