fast-user-switch restart/shutdown dialogues do not always appear

I'm setting this to incomplete because I really can't reproduce it. If you can come up with some way, that'd be great. Are you sure that you just don't miss the dialog somehow? Have some setting that puts it behind other windows or something like that? Also, when you see this behavior are other users logged into the system or is there only one? Is it always on the same account?

> Are you sure that you just don't miss the dialog somehow? Have some setting that puts it behind other windows or something like that?

Absolutely positive the dialogue does not appear. The action is taken immediately I select the option from the user switch menu. I don't even have time to move my mouse anywhere near where the dialogue should appear. There are no other users on this machine, it is always the same account.

I'm not sure how I can collect further information. Are there any log files I can check? May be I could build my own version and sprinkle in some debug.....

On Tue, 2009-03-24 at 08:22 +0000, Paul Broadhead wrote:
> I'm not sure how I can collect further information. Are there any log
> files I can check? May be I could build my own version and sprinkle in
> some debug.....

There are some debug messages that get printed currently, I'm not sure
how many relating to the dialog though. If you run a command line like
this you can get them:

  $ killall fast-user-switch-applet
  $ /usr/lib/fast-user-switch-applet/fast-user-switch-applet

After the kill you'll get a dialog to reload it, but don't click to
reload until after you've executed the second command. That'll make it
execute in the terminal.

Thanks Ted. I did as you suggested, redirecting to a log file using "&>". I got lucky as the first time I selected "Restart", the action happened immediately, no countdown dialogue. I've attached the log file.

I confirm this bug.

steps to reproduce:
1. open gnome-terminal
2. type: su $USER
3. select "Restart..." in fast-user-switch-applet
--> computer immediately restarts without confirmation dialogue

Well done Luka, that does appear to make the bug 100% reproducible. I was beginning to think I was the only one with this problem.

However, there must be some other cause than just "su $USER" as I do not believe I have done that at all recently and I see the bug most days (I often check even if I do not want to restart). I do often "sudo -i" to get a root terminal but that does not trigger the problem.

I tried "su <some other user>". That prompted me for admin access, when given the restart was immediate. Also, if I ssh in from another machine as the desktop user, the restart is immediate too.

On Sun, 2009-04-05 at 15:32 +0000, Luka wrote:
> steps to reproduce:
> 1. open gnome-terminal
> 2. type: su $USER
> 3. select "Restart..." in fast-user-switch-applet
> --> computer immediately restarts without confirmation dialogue

Okay, so what I'm guessing what happens is that the code to detect
whether we need a PolicyKit prompt looks at the number of sessions that
exist. It sees there are two, and then assumes that it's a multi-user
logout situation. The reality is that since their the same user,
PolicyKit assumes you know what you're doing to you, and allows it to be
a single user logout.

The change needed is to make the multi-user check function look to see
if they're all the same user name or not.

Thanks!

Ted, the teh FAIL here is there are two separate (different) tests for whether the action should be instant.

If the course of action is determined by current log in status, then the menu-item needs to be set based on *the same test*.

Alternatively, if the menu-item text is set based on a Gconf key, then the course-of-action needs to be based on *the same test* of checking the Gconf fail.

At the moment, the left-hand doesn't know what the right-hand is (about to be) doing.

On Fri, 2009-04-10 at 10:02 +0000, Paul Sladen wrote:
> Ted, the teh FAIL here is there are two separate (different) tests for
> whether the action should be instant.
>
> If the course of action is determined by current log in status, then the
> menu-item needs to be set based on *the same test*.
>
> Alternatively, if the menu-item text is set based on a Gconf key, then
> the course-of-action needs to be based on *the same test* of checking
> the Gconf fail.
>
> At the moment, the left-hand doesn't know what the right-hand is (about
> to be) doing.

Paul,

I think you're missing a little part of the logic here. What we're
checking for to not show the dialog is two things:

  1) Has the user asked us not to in GConf
  2) Will PolicyKit popup a dialog asking for a password

So if the GConf key is set we should ALWAYS show a dialog, the question
becomes which one. The problem here is that we're misdetecting when
PolicyKit is going to show his, so we end up falling through the case of
not showing anything.

  --Ted