System -> Quit takes a long time to appear

[Marc Tardif]

Immediately after logging in, selecting System -> Quit takes more than a minute for the window to appear.

If waiting a few minutes after logging in, then selecting System -> Quit is much more responsive.

Also, when having to wait more than a minute for the window to appear, the options available aren't all available. For example, the suspend and hibernation options are simply not there. However, after waiting a few minutes, those options are available again.

Saivann : This bug can be reproduced when the gnome-power-manager is not checked in System / Preferences / Session options .

[Serge (serge-de-souza)]

Also nm-applet and gnome-power-manager icons take a while to appear

The splash screen waits on gnome-volume-manager.

Changing the start order of /usr/lib/evolution/2.12/evolution-alarm-notify to 60 (previous value = 50) fixes the problem: All items in the session start promptly.

This is for gutsy with all updates applied at time of writing.

[Serge (serge-de-souza)]

Marc can you confirm this?

Do we need more information on this one?

[Sebastien Bacher (seb128)]

Thank you for your bug. Do you still have the problem? Does it happen every time? Do you use compiz?

[Serge (serge-de-souza)]

Installed with Tribe-2, the problem was there. I re-installed with
Tribe-3 and it the problem seems to have been fixed.

Thanks

[Brian Murray (brian-murray)]

Marc - this seems to be resolved with Tribe 3 can you confirm this?

[Paul van Genderen (paulvg)]

When this happens, it might be caused by an unconfigured loopback interface. To fix that, type this into a terminal:

sudo ifdown lo
sudo ifup lo

ifdown makes sure that /var/run/network/ifstate doesn't list lo

[Martin Pitt (pitti)]

It is also very likely that this was related to compiz. Check gnome-session-properties, which program currently tries to attach to the session. For me, compiz often failed to connect and then timed out after 60 seconds. After it, the other services connected to the session (which are responsible for the quit dialog, automounting, etc.).

[Martin Pitt (pitti)]

This has not been observed any more since Tribe 3, and both the "compiz session connect" hang and the gnome-power-manager interface renaming bugs have been fixed since then. Therefore I am closing this.

Please reopen if it still happens on Tribe 4 for you. Thank you!

[Wilbur Harvey (wilbur-harvey-spirentcom)]

I am running tribe5 with all the updates as of 2007-Sep-06 noon HST, and I still have this problem.
sudo ifdown lo
sudo ifup lo
seems to make the response to a quit work at normal speed.
I also have the problem that when I right click, I cannot open a terminal. The option is there but nothing happens.
Also, if I quit and then log back in, I never get logged back in.

[Gaëtan de Menten (gdementen)]

I have this problem with an updated gutsy as of now (27/09). sudo ifdown etc... doesn't seem to change anything.
It's probably related to compiz since when I disable the effects, it works normally.

[David Tomaschik (matir)]

I've seen this same behavior with compiz disabled as well.

[Gaëtan de Menten (gdementen)]

Ok, I've experienced the problem with compiz disabled too, so nevermind my post. The true workaround (found thanks to a post at lwn) is to have gnome-power-manager in your session (which I had removed since I don't have a laptop).

[Gaëtan de Menten (gdementen)]

As mentioned in my previous comment, it still happens if the user has no gnome-power-manager in his session (which worked fine in Feisty). I'm reopening the bug, just to make sure you know about it since I don't know if you want to support that case.

[Sebastien Bacher (seb128)]

How did you remove it from your session?

[Gaëtan de Menten (gdementen)]

I had disabled it in Feisty, so I don't remember, but I suppose that I had removed the entry about the power manager in system->Preferences->Sessions. Seems like I didn't disable it since it wasn't in the list at all.

[Timo Jyrinki (timo-jyrinki)]

Setting to Confirmed. Indeed if I remove (like I did) gnome-power-manager from the autostart list (System->Preferences->Sessions), gnome-session-save --kill or clicking the Quit icon or selecting System->Quit results in ca. 60s wait. If I cancel it, the next time it works as normal. If I logout and login again, the 60s wait is there again.

Relieved to having found what was the cause of the problem, though... it was really annoying.

[Ming Hua (minghua)]

Let me add that I was bitten by this bug as well.

I installed using Gutsy beta i386 alternative CD on a desktop computer, the gnome power manager is not started in System -> Preferences -> Sessions dialog after installation.

Enable the power manager in the Session dialog fixes the long delay.

[Matthew Tighe (tighem)]

I'm experiencing this problem and have gnome-power-manager enabled in the session box. It affects the gnome-panel applet as well as the awn power button applet. It appears to me that gnome-session-save is hanging. I have a strace of that script running that ends in a kill because it hangs when run.

[Michał J. Gajda (mgajda)]

The same with gnome-power-manager both disabled and enabled. The same setup worked well in Feisty.

gnome-panel is unresponsive until "System>Quit" window appears.

[hob4bit (hob4bit)]

***** WORKAROUND ******

There is a workaround. The "gnome-power-manager_2.20.0-0ubuntu6" package is buggy.
Just down grade to Fiesty version:

wget http://uk.archive.ubuntu.com/ubuntu/pool/main/g/gnome-power-manager/gnome-power-manager_2.18.2-0ubuntu3_amd64.deb
wget http://uk.archive.ubuntu.com/ubuntu/pool/main/libw/libwnck/libwnck18_2.18.0-0ubuntu1_amd64.deb
wget http://uk.archive.ubuntu.com/ubuntu/pool/main/libw/libwnck/libwnck-common_2.18.0-0ubuntu1_all.deb
dpkg -i gnome-power-manager_* libwnck18_* libwnck-common_*

This is what I do with Ubuntu problems nowadays. Any package with bug I just down grade to latest
stable released.

[Sebastien Bacher (seb128)]

Could you describe how the package is busy rather than advising users to downgrade to a version not tested on gutsy?

[hob4bit (hob4bit)]

Hi again, I dunno but somebody in the thread/related thread mentions problems
with "gnome-power-manager". My problem is that quitting takes one minute or so.
This problem did not occur with Feisty. So I tried down grading just this package
plus two dependencies to Feisty versions. This seems to fix my problems.

If you want a workaround this should be good enough. A real fix can take some time.
I have reported bugs with feisty which still have not been fixed in Gutsy. In that
case I keep soem packages at "edgy" versions.

I am very surprised that gutsy has been released with such bugs in the first.
I hope Ubtutu 8.04 is better as this will be long term support.

From my experience with Feisty and Gutsy workarounds for bugs can be found
by rolling back to earlier releases.

[Guillaume AVRIL (guillaumeavril)]

Hi!

I had the same bug and it seems to be resoved for me now! I did two things and I can't tell wich one was the good one:

Firstly, on my desktop computer I re-enabled gnome-power-manager.
Secondly, I changed my /etc/hosts file by adding my hostname in the 127.0.0.1 line.

http://ubuntuforums.org/showthread.php?t=388765

Can someone confirm this?

Thx & good luck

[Fjodor (sune-molgaard)]

I see "logout dialogue takes a very long time to appear" and "no options for suspending/hibernating (not always, though, but mostly) on a desktop (upgraded time and time again since 5.04), a laptop (upgraded from 7.04, then to 7.10), another laptop (upgraded from 7.04 to 7.10) and a desktop installed from last beta of 7.10 and upgraded accordingly.

Something is clearly wrong!

/Fjodor

[Zenwalker (shailesh-zenwalk)]

So when this bug will be fixed??

[Psykotik (linux-ikiru)]

I confirm the guillaume's solution works. It solved my problem.

[WillTH (thornton-will2003)]

Same problem here...was having real problems with the cpu scaling and system freezes making my PC unuseable. After much searching I switched the scaling function off in the bios and disabled the gnome power manager etc. At last I can use the PC to do some work instead of screaming at the screen all day. This is my first foray into Linux... and apparently ubuntu just works so i fear for newbies to other distros!

Was it a good idea to turn the power manager off? I use a Pundit that employs Q fan technology... chip seems to be happy with it off though?? How best to check temps fan speeds etc?

So with gpm off i have a useable operating system where i can work/surf/play and do everything except shut down the pc without planning the event some time in advance. This problem is described elsewhere (selecting shut down freezes desktop (except mouse) for minute+ and then panel with shut down options appears as normal and shut down/log out can be initiated).

System info.

Asus Pundit P1-AH2
AMD Athlon(tm) 64 X2 Dual Core Processor 4000+
512MB DDR
C51PV [GeForce 6150]
Gutsy 7.10
Kernel Linux 2.6.22-14-generic
Gnome 2.20.1

Hope there will be a fix soon... nothing seems to work thus far...

[WillTH (thornton-will2003)]

"So when this bug will be fixed??"

I'm holding my breath (!) but as it is a low priority setting i guess we have a long wait and/or it will be carried over into the next release?? Looks like i will have to dig out those micro$oft disks...

[Sebastien Bacher (seb128)]

The bug will be fixed when somebody will have a clear description of the issue and a way to trigger it easily so it can be debugged. The current comments are not really useful, it's clear some people have the issue but none of those are able to debug and fix it apparently and there is not enough informations to allow somebody not having the bug to work easily on the issue

[Saivann Carignan (oxmosys)]

This bug will be fixed when a developer will find and fix the problem. Anybody ( that has some programming skills ) can work on this. For your problem, I'm sure that you can find a solution that doesn't require to disable GPM. However, I think that you'll get the what you need here : https://answers.launchpad.net/ rather than in the bug report which should only contains comments and informations that will help developers to make fast and proper fixes. If this bug report gets too much comments that are not directly providing important informations, most probably that it will be difficult for developers to work on it and fix it. Thanks for your participation!

[David Cassidy (davidcassidy)]

I discovered that I too had been affected by this bug after a dumb attempt to speed things up a little and removing gnome-power-manager from the list of startup applications. Adding it back to the startup applications and adding it to my current session corrected the issue immediately as well as restored my hiberante and suspend options. I wish I had more to tell you, but it seems that, in my case at least, I created the issue.

[Sebastien Bacher (seb128)]

Did everybody subscribed to this bug broke his session by disabling gnome-power-manager or is there users having a bug using the normal ubuntu configuration?

[Guillaume AVRIL (guillaumeavril)]

I had the bug just after installing ubuntu. So it was with the normal
configuration. I have another Ubuntu 7.10 virtualized using Virtual Box and
it is affected by this bug, so you can try if you want.
Good luck

On Jan 14, 2008 9:52 AM, Sebastien Bacher <email address hidden> wrote:

> Did everybody subscribed to this bug broke his session by disabling
> gnome-power-manager or is there users having a bug using the normal
> ubuntu configuration?
>
> --
> System -> Quit takes a long time to appear
> https://bugs.launchpad.net/bugs/123078
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[charsi (charsi)]

i think for most the proble was only the disable gnome-power-manager

On Mon, 14 Jan 2008 14:22:03 +0530, Sebastien Bacher <email address hidden>
wrote:

> Did everybody subscribed to this bug broke his session by disabling
> gnome-power-manager or is there users having a bug using the normal
> ubuntu configuration?
>

[André (andred-ubuntu-deactivatedaccount-deactivatedaccount)]

This bug is triggered for me too if I disable gnome-power-manager in my session. I have reproduced it with both Gutsy and alpha 5 of Hardy. Let me know if I can provide any information that may be helpful in resolving this issue.

[André (andred-ubuntu-deactivatedaccount-deactivatedaccount)]

When this bug happens, the below (identical) lines are written to ~/.xsession-errors. The logout dialog appears at the same time as the second time this message is logged. It appears as if it gives up trying to connect to PowerManager after a given time.

** (x-session-manager:5639): WARNING **: Couldn't connect to PowerManager Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

** (x-session-manager:5639): WARNING **: Couldn't connect to PowerManager Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

[Hanusz leszek (leszek-skynet)]

I encountered this bug after upgrading to hardy.
I can confirm:
 - enabling gnome-power-manager in the session solves the problem
 - I received the same error messages than André in .xsession-errors

[323232 (323232)]

Encoutered bug after upgrading Hardy Beta
+ powermanager is enabled
+ Quit does not respond after login
+ After starting an application -like fire fox- the quit box (Logout, Quit, Restart etc) appears and a can logout.
+ After loging out and login (to an other account) -> same issue

[Guillaume AVRIL (guillaumeavril)]

no problem for me in Hardy Beta

On Sun, Mar 30, 2008 at 3:16 PM, 323232 <[e-mail]> wrote:

> Encoutered bug after upgrading Hardy Beta
> + powermanager is enabled
> + Quit does not respond after login
> + After starting an application -like fire fox- the quit box (Logout,
> Quit, Restart etc) appears and a can logout.
> + After loging out and login (to an other account) -> same issue
>
> --
> System -> Quit takes a long time to appear
> https://bugs.launchpad.net/bugs/123078
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[323232 (323232)]

After todayś update: Not anymore an issue. WoRks fine

[323232 (323232)]

And after today's update: Problem is back!

[Oleksij Rempel (olerem)]

After i cleanet my settings, newe had this problem agene and can't reproduce it anymore.

[323232 (323232)]

Also made a new account and the problem disappeared when using this new account.
When you use an existing account the problem is still there.
Found out that when you -> delete /home/???/.gconf/apps/panel, -> logout and -> login the problem disappears
-->> untill you make some changes in the top panel / or delete the top panel (en put a quit button in the lower panel.)
The problem reappears then.

Reminder problem:
+ Quit does not respond after login
+ After starting an application -like fire fox- the quit box (Logout, Quit, Restart etc) appears and a can logout.
+ After loging out and login (to an other account) -> same issue

[323232 (323232)]

Extra detail: after changing panel -> logout -> login -> problem reappears of course.

[Timo Aaltonen (tjaalton)]

Gnome-session checks that if gpm is running and asks hal to start it (?), which it does. So, there's no way to actually disable gnome-power-manager now, and IMO this is should deserve a priority higher than "low"...

[Chocwise (chocwise)]

Confirmed as well. I use Hardy Final now, had the Problem from the start because I upgraded from Gutsy and had the gnome-power-manager disabled before already. Googled a little and found that workaround with reenabling gnome-power-manager. The Shutdown-Dialog starts now immediately.

[Eric Riese (jebuswankel)]

Same thing happened to me as Chocwise 100%, except when I googled it I found the solution on this page.

[Jani Monoses (jani)]

I see this too on two computers since Hardy where g-p-m is disabled. The logout dialog code checks to see if suspend and hibernate buttons are to be added and asks g-p-m. However if it is not running it does not get the answer and it blocks. g-p-m is started by this but possibly too late to answer. Subsequent attempts to log out work since g-p-m has been started.
Any other app that talks to g-p-m via dbus can wake it up so maybe this is why sometimes it works and sometimes not for some users.
It can be reproduced by killing g-p-m and trying to log out (button or gnome-session-save --kill)

Killing g-p-m then calling for example
dbus-send --session --print-reply --dest="org.freedesktop.PowerManagement" --type=method_call --reply-timeout=6000 /org/freedesktop/PowerManagement org.freedesktop.PowerManagement.CanSuspend
restarts g-p-m then quit works.

The logout code seems to hang on AddMatch . Had g-p-m been running the AddMatch/RemoveMatch pairs below would have delimited calls to CanSuspend and CanHibernate

method call sender=:1.0 -> dest=org.freedesktop.DBus path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "type='signal',sender='org.freedesktop.PowerManagement',path='/org/freedesktop/PowerManagement',interface='org.freedesktop.PowerManagement'"
method call sender=:1.0 -> dest=org.freedesktop.DBus path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=RemoveMatch
   string "type='signal',sender='org.freedesktop.PowerManagement',path='/org/freedesktop/PowerManagement',interface='org.freedesktop.PowerManagement'"
method call sender=:1.0 -> dest=org.freedesktop.DBus path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "type='signal',sender='org.freedesktop.PowerManagement',path='/org/freedesktop/PowerManagement',interface='org.freedesktop.PowerManagement'"
method call sender=:1.0 -> dest=org.freedesktop.DBus path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=RemoveMatch
   string "type='signal',sender='org.freedesktop.PowerManagement',path='/org/freedesktop/PowerManagement',interface='org.freedesktop.PowerManagement'"

[Shane Hill (shane-hill)]

G'day All,

I also geeting the same problem, but not on the main console. I only get this problem when I login using XDMCP from a remote terminal. I have g-p-m running, so all I can think of is that g-p-m does not interact correctly when running from a remote session. This bug is very frustrating and I'd prefer remote users to logout cleanly and not just terminate the remote session software (like Cygwin X server or X-Win32 under MS Windows).

[Tiede (marcarthur)]

I am writing to confirm same bug on my GF's PC. I may have disabled gpm on it, to try and make her PC faster... I will re-enable it and see what happens.
I will enable it and see what happens then... BTW, though, does that mean we could have a fix coming soon? -- since Jani Monoses seems to have pinpointed the problem...

[Arthur Furlan (afurlan)]

Hello, I think that I found a solution... I tested (and retested) and it works for me.
To discover what's the problem that was causing the longer time I executed

    $ tail -f ~/.xsession-errors

and then I executed

    $ gnome-session-save --kil

that is the same command that runs when you click on "Session > Quit" button.
After some time I got the following message

    ** (x-session-manager:7532): WARNING **: Couldn't connect to PowerManager Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

It occurs for me because I disabled the gnome-power-manager of session startup (I have a desktop, so it's unecessary).
To solve the bug I opened the "System > Preferences > Sessions" and added the gnome-power-manager as a startup program.

Anybody can confirm if it really solves the problem?

[Evan Huus (eapache)]

It looks like there are actually several bugs here.

One is that "gnome-session-save --kil" calls gnome-power-manager and takes 30 seconds to time out. It should check if gnome-power-manager is running before making the call, and skip that step if it isn't. This should be easy to fix, and can be worked around by reenabling gnome-power-manager in the sessions box.

The other bugs seem to have something to do with gnome-panel and should probably be split to their own bug.

Can somebody at least fix the first one? It seems like it's been fairly well documented.

[Nicolas Michel (nicolas-michel)]

I need to confirm what Arthur Furlan told. I also had this problem of waiting a long long time before the quit window comes.
I had also unchecked "gnome-power-manager", thinking it would be unnecessary for my desktop computer.

I tried the tip of Arthur : I re-checked the "gnome-power-manager" in the sessions' preferences to make it active and the bug is disappeared immediatly with the next login session.

[Christian Vogel (vogelchr)]

This seems to be a deadlock with regards to the session manager. I also have g-p-m disabled in my session options... When I replace /usr/bin/gnome-power-manager by a shell script that starts the real gnome-power-manager under strace, I get the following debugging output:

---------> Output of strace -o /tmp/gnome-power-manager.$$ /usr/bin/gnome-power-manager.orig
connect(12, {sa_family=AF_FILE, path="/tmp/.ICE-unix/6166"}, 21) = 0
fcntl64(12, F_SETFD, FD_CLOEXEC) = 0
write(12, "\0\1\0\0\0\0\0\0", 8) = 8
read(12, 0x80c7770, 8) = ? ERESTARTSYS (To be restarted)
--- SIGTERM (Terminated) @ 0 (0) ---

Note that gnome-power-manager connects to the session manager, sends a packet and then waits indefinitely (it has been killed by me with SIGTERM after some time).

$ env|grep SESSION_MANAGER
SESSION_MANAGER=local/enormity:/tmp/.ICE-unix/6166

[Marian Sigler (maix42)]

This bug still appears on hardy.

[Chris Coulson (chrisccoulson)]

This appears to be fixed in Jaunty now. If gnome-power-manager is not running, gnome-session doesn't wait around before displaying the dialog.

[Saivann Carignan (oxmosys)]

I confirm, this is fixed. Thanks!