XFCE Logout hangs for a few minutes

[Yuv]

Fresh install, Xubuntu 14.01 amd64.
When I either press the computer's power button or the Logout Button in the Whisker Menu, the computer hangs, more or less unresponsive, for a few minutes, before showing me the choices of logout, reboot, or shutdown.
Workaround: open a terminal window and `run sudo shutdown -P now` to achieve the expected result.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: xfce4-session 4.10.1-3ubuntu5
ProcVersionSignature: Ubuntu 3.13.0-24.47-generic 3.13.9
Uname: Linux 3.13.0-24-generic x86_64
ApportVersion: 2.14.1-0ubuntu3
Architecture: amd64
CurrentDesktop: XFCE
Date: Tue May 13 20:28:13 2014
InstallationDate: Installed on 2014-05-12 (1 days ago)
InstallationMedia: Xubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140416.2)
SourcePackage: xfce4-session
UpgradeStatus: No upgrade log present (probably fresh install)

[Jppande (jppande)]

when clicked on Logout option from applications menu or xfce4-session-logout from commandline, the logout dialog appears very late (after ~2mins).
a message (xfce4-session:CRITICAL dbus_set_g_error could not verify == NULL(not exact msg) ) is displayed at ctrl+alt+F1

Problem arises for users: normal user and root as well
OS: LFS
dbus, consolekit installed, working well.

[Kaurman-o (kaurman-o)]

Any news on that one? I've been experiencing something very similar for quite a while. Running xfce 4.10 on arch. Everything else seems to work ok but the logout dialog takes ages to appear and the rest of the system is somewhat slow to respond until it does.

True, *the dialog appears fine if to switch to another runlevel and back after clicking the 'logout' button*.

Any ideas on how to find out if it actually is (an xfce) bug in the first place?

PS /var/run/ and /var/lock/ are symlinks as they should be in the case of arch (some have reported similar issues when they are not).

[Matthias (annos)]

Hi, same issue for me. When hitting the logout button in the menu or running xfce4-session-logout from a terminal Xorg CPU usage goes up till nearly 100%. System is very slow and logout dialog takes 2 - 5 min to be displayed.

However, I can also confirm that switching to another terminal resolves the issue. Dialog is displayed immediatly after switching back.

Running "xfce4-session-logout -l" works fine. Disabling Setting --> Session and Startup --> "Ask before logout" resolves the issue too. Looks like a problem with the GUI to me.

[Kaurman-o (kaurman-o)]

I have some good news. I discovered a few days ago that the bug is gone for me.
The bad news is that I have no idea what 'fixed' it since I have made quite a few changes during the past few days. The biggest was getting the proprietary ati driver instead of the open alternative but I seriously doubt this has anything to do with the bug. One of the things I messed with as well was the theme of my desktop (theme as such + icons).

I'll try and see if I can reverse the changes I've made and will report should I find something. As for the theme & icons, this doesn't seem to be the thing but you may try just in case.

I'm not sure whether cpu usage was high when I suffered from the bug. I should have noticed but who knows.

[Matthias (annos)]

I'll give the proprietary driver a try. Or at least make a testrun with the default vesa driver.

[Matthias (annos)]

Ok, looks like the radeon driver is part of the problem. Started my arch with kernel parameter "xforcevesa" and tried to log out ... no problem.

[Kaurman-o (kaurman-o)]

You don't say... I didn't consider it too likely. Still, glad to hear. I think you should file a bug report against the driver then. If you do, be sure to share the link. It'd be interesting to observe.

True, we can't still be 100% sure that the radeon driver is to blame. It may be, as you said, 'part of the problem'. Still, based on the above comments we have considerable grounds for being suspicious about the driver so I think reporting can't hurt. At worst they'll just make us find out that the driver isn't to blame after all.

[Matthias (annos)]

True, true. Nevertheless, I still consider the xfce team responsible for the bug. Shurely they can give a much more specific description to the xorg team than I can.

Let's wait what they have to say ...

[Matthias (annos)]

Just found out there allready is a bug reported against the driver :

https://bugs.freedesktop.org/show_bug.cgi?id=68524

Seems to be an issue with the glamor rendering. They suggest to force EXA instead via

Option "AccelMethod" "EXA"

in your xorg.conf "Device" Section.

[Kaurman-o (kaurman-o)]

(In reply to MS from comment #8)
>
> Seems to be an issue with the glamor rendering. They suggest to force EXA
> instead via
>
>
> Option "AccelMethod" "EXA"
>
>
> in your xorg.conf "Device" Section.

Thanks for the info. Works like a charm. (I decided to abandon the proprietary driver after another X version issue.)

[Matthias (annos)]

Tested for 2 days now. Works for me ,too. I suggest to close this bug as it is related to the driver.

[Yuv (yuv)]

Documenting the workaround for people who bumps in the same issue (documentation around the web is scattered and unclear).
* start a terminal (pressing the key combination Super+T should do)
* enter the following commands to create the configuration file
  sudo mkdir -p /etc/X11/xorg.conf.d/
  sudo nano /etc/X11/xorg.conf.d/20-radeon.conf
* in the configuration file, enter the follwing lines
  Section "Device"
      Identifier "Radeon"
      Driver "radeon"
      Option "AccelMethod" "EXA"
  EndSection
* press CTRL+X, then Y to save

[Yuv (yuv)]

Worked for me too. Documented workaround in Launchpad
* start a terminal (pressing the key combination Super+T should do)
* enter the following commands to create the configuration file
  sudo mkdir -p /etc/X11/xorg.conf.d/
  sudo nano /etc/X11/xorg.conf.d/20-radeon.conf
* in the configuration file, enter the follwing lines
  Section "Device"
      Identifier "Radeon"
      Driver "radeon"
      Option "AccelMethod" "EXA"
  EndSection
* press CTRL+X, then Y to save

IMHO, rather than closing the bug, if shipping the workaround s not too difficult it would be more user-friendly to implement the workaround in the XFCE .deb package until the driver is fixed.

[Launchpad Janitor (janitor)]

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

[Eric Koegel (eric-koegel)]

Marking bug as closed per last comment. Please reopen this report if you can still reproduce it.

[Thaddaeus Tintenfisch (thad-fisch-deactivatedaccount)]

According to the discussion in the upstream bug report, this is not a bug in xfce4-session.

[Launchpad Janitor (janitor)]

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

[F66168 (europe66168)]

Related to the driver ?
Xfce team had fixed it for xubuntu 15.04, why not for xubuntu 14.04 ?

[penalvch (penalvch)]

Yuv, thank you for taking the time to report this bug and helping to make Ubuntu better. Please execute the following command, as it will automatically gather debugging information, in a terminal:
apport-collect -p xorg 1319220

Please ensure you have the package xdiagnose installed, and that you click the Yes button for attaching additional debugging information.

When reporting bugs in the future please use apport by using 'ubuntu-bug' and the name of the package affected. You can learn more about this functionality at https://wiki.ubuntu.com/ReportingBugs.

[Yuv (yuv)]

This bug has long been fixed. Comment #20 is absolutely unnecessary and the kind of comment that makes me reconsider contributing bug reports at all.