xfwm4 is not running after failed shut down / "session manager must be in idle state when requesting a shutdown"

Created attachment 2363
mousepad patch that displays YNC prompt on session logout (demo only, won't save if you choose "yes")

When logging out, and 2+ application issue interact requests during their save-yourself-s, and (at least?) one of them actually starts interacting, the session manager will not continue normally when the interaction completes. Instead, it will wait 1 minute, and then forcibly close the session. During this period, a second logout attempt will say that the session manager must be idle when requesting shutdown.

It's OK if there is only 1 app with interactive save yourself, or there are 2 apps, but none of them actually interacts.

For example, patch a mousepad, run 2 copies of it, type "boza" in the first copy and try to logout. A yes/no/cancel prompt will be displayed, but after you answer, the second mousepad (and thus the whole session) will remain for 1 minute - or until you close the it. YMMV, I received an ICE I/O error once.

It's not a libxfcegui4 session-client problem, I tried with non-xfce apps as well.

Maybe it's not the interaction by itself that matters, but the longer time interval between interact request and interact done?

Reassign to <email address hidden>.

Title bar, buttons to diminish, expand, quit window - disappeared. Windows
stick to upper left-hand corner of screen with no way of moving them. A log out
and log-in solved the problem.

This has both been experienced in Magaeia XFCE version 4.8.1 and in Xubuntu XFCE version 4.8.0. In Xubuntu it has been necessary to force a restart of XFWM4, to solve the problem.

Looks like a dup of bug #7864 and bug #7866 but still the same problem, it works for me and I would need someone to get a core file if any, open that in gdb and do some initial investigation.

Maybe try to contact your distribution maintainers, I believe they should be able to assist you in getting a backtrace with symbols.

Also, the first thing to determine is if it's really an issue at startup (ie xfwm4 is listed in the session for next restart) or if it's with the logout, ie xfwm4 is removed from the session and therefore is not restarted later.

So when that happen, first thing is to check if xfwm4 is listed in your session in ~/.cache/sessions/xfce4-session-<display>

I'll look in the path the next time I experience the problem. The issue has also been posted to Mageia. They asked me to also pass a bug report on to you.

I have identified a potential crash which may occur at logout, which may cause
xfwm4 to not be restarted at next login, which would explain why it's not there
when you log in.

Fix is in git, both branches master and xfce-4.8, could you try that and
report?

Something else I've noticed (on my 4.8.2-1 debian sid package), is that if windows in a saved session are open in multiple workspaces, the symptoms do not manifest.

If the symptoms do manifest (saved session with application windows in a single workspace only), the workspace count is reduced to 1.

Correction, symptoms still manifest if windows are open across every workspace. In fact, having windows open in every workspace seems to be a method to reproduce this.

Looks like xfwm4 is not in the sessions file.

See comment #4

Got the git build (HEAD off of the xfce-4.8 branch) done and installed it.

My testing indicates that the problem is gone (logoff/logon with applications open in all windows, followed by restart with applications open in all windows); I'll make another post in a couple days if I run into the symptoms again.

Symptoms still appearing using patched version. Any idea where a coredump might live so I can attach it?

(In reply to comment #9)
> Symptoms still appearing using patched version. Any idea where a coredump might
> live so I can attach it?

Location and naming of core files on Linux can be set using the kernel params:

  kernel.core_uses_pid
  kernel.core_pattern

You may want to check with your distribution what's the best place to set these (usually /etc/sysctl.conf)

It is not clear if the program segfaults in your case or else if this is a bug in the new implementation of session management added by Nick and Stefan in 4.8, so that should be determined first.

Note that a core file won't be useful in this bug report because I am not using the same distribution as you, so unless the core file contains all the debugging symbols and the binary statically linked (which is definitely not the case), I won't be able to make any sense of such a core file.

Brian's put some instructions on how to help debugging here:

  http://spurint.org/projects/xfce4-debugging/

Just checking, but did you install the build from source in the same path as the original build or in /usr/local (default)?

Was xfwm4 restarted after installation?

If not, can you check if the version used is the one from the source build and not still the original one, just in case?

I made sure to drop it in /usr/bin (overwriting my distro package).

>which xfwm4
/usr/bin/xfwm4

Here's the version string (xfwm4 -V):
This is xfwm4 version 4.8.2git.6c6d216 (revision 6c6d216) for Xfce 4.8
 Released under the terms of the GNU General Public License.
 Compiled against GTK+-2.24.8, using GTK+-2.24.8.

And to confirm, I've restarted xfwm several times after installing (system resets, logoffs, killing xfwm, etc).

If it crashes, I would really need at a bare minimum a backtrace to have an idea of where to look.

Description of problem:

Upgraded to centos 6.1 and rebooted. After login:
1) no window decorations ('xfwm4 --replace' fixes that).
2) no workspaces (used to be 4). (Fixable via settings manager.)

Version-Release number of selected component (if applicable):

xfce4-panel-4.8.3-2.el6.x86_64
xfce4-doc-4.8.3-1.el6.noarch
xfce4-session-4.8.1-4.el6.x86_64
xfce-utils-4.8.3-1.el6.x86_64
xfce4-session-engines-4.8.1-4.el6.x86_64
xfce4-power-manager-1.0.10-1.el6.x86_64
libxfce4ui-4.8.0-4.el6.x86_64
libxfce4util-4.8.1-2.el6.x86_64
xfce4-appfinder-4.8.0-2.el6.x86_64
xfce4-mixer-4.8.0-1.el6.x86_64
xfce4-settings-4.8.3-1.el6.x86_64
xfce4-icon-theme-4.4.3-5.el6.noarch
xfwm4-4.8.1-3.el6.x86_64

OK, a couple of restarts later: I verified that xfce4-session is not starting the window manager, and that # of workspaces is reset to 1 on every login.

Are you sure you are saving a session with xfwm4 running? and it's completing ok?

Anything in ~/.xsession-errors related to a xfwm4 crash?

Does making a new clean user show the same behavior?

"No", "no", "not tried b/c #1 is the correct answer".

So the best guess is initially, after I ran yum update and hit "restart" button on the logout dialog, the session got somehow saved with xfwm4 not running?

After that I was starting xfwm4 from an xterm without '&', I can see how that would kill the wm before saving the session.

Thanks.

Yeah, that seems to be the case. ;(

We have seen sporadic cases where a logout has a xfwm4 crash, then it doesn't get saved in the session. Causing it to not show up in later sessions. ;(

We have not been able to track down the issue. ;(

I can reproduce probably this bug with:
- start empty xfce4-session
- start firefox
- start gedit and type something to have unsaved changes
- do a xfce4-logout ("/usr/bin/xfce4-session-logout --logout")
=> 60s timeout, then logout. incomplete session at startup (no gedit, no xfwm4 started by session manager).

Session works fine, if:
- firefox not running or
- gedit hat no unsaved changes or
- gedit is not running

Seems that gedit does not get any shutdown message (since it does not show any dialog) if firefox is also running.

Problem occures with up-to-date opensuse 11-4 (with X11:xfce repository) and with my Xubuntu 11.10 "Oneric Ocelot". (xfce4-session 4.8.2, 2011-12-27)

(Thanks to Jérôme Guelfucci who lead me to this bug.)

We have had several folks in Fedora reporting that their xfwm4 somehow doesn't get saved in their session. I wonder if this could be the cause. Will try and gather more info.

> start firefox
> start gedit and type something [...]

Yes. Unfortunately, with 4.8, even a single xsmp interact request may break the session logout.

Hi,

I have almost the same problem since I started using XFCE few months ago (Gnome3 convinced me). Debian sid here (3.1.0-1-amd64).

On my side, I could not figure out exactly when it happens... maybe like 1/3 of the times. I don't think it's related to the number of open windows and/or workspaces, I would have noticed it. I guess its crashing at logout since there is no xfwm4 entry in ~/.cache/sessions (well, at least in the affected session). Also, my workspace count is not reduced to 1, but to 2 (instead of my usual 4).

It's getting pretty annoying to "ALT-F2 -> xfwm4" each time, so I'd like to help. I cannot reproduce it at command, though I think I could manage it anyway.

I've read http://spurint.org/projects/xfce4-debugging/. Good stufs, but before I did into building a reliable debug version, I wonder if there is a simpler way. If I install the xfwm4-dbg package provided in the Debian repository, isn't it enough? Then what should I do to make use of it? I'm a developper, but not very used to Linux dev, though I know how to use gdb. Can I launch xfwm4 in gdb with some arguments to make it use the xfwm4-dbg symbolic infos? Could you give me a hint or two?

(In reply to comment #2)
> Also, the first thing to determine is if it's really an issue at startup (ie
> xfwm4 is listed in the session for next restart) or if it's with the logout, ie
> xfwm4 is removed from the session and therefore is not restarted later.
>
> So when that happen, first thing is to check if xfwm4 is listed in your session
> in ~/.cache/sessions/xfce4-session-<display>

Same problem on Fedora 16 Xfce (no mod). But in my case the logout, login or reboot don't have solved the issue. Only removing ~/.cache/sessions/xfce4-session-<display> have restored to the 'normal' situation.
Running xfwm4 from terminal, restore the WM, but xfwm4 don't run at startup anyway..

I am not having trouble with window decorations, but I am having trouble with the number of workspaces being reset to 1. I can also set the number of workspaces manually every time I login. I'm using F16 on 686.

There are two bugs for this on launchpad https://bugs.launchpad.net/ubuntu/+source/xfwm4/+bug/495361 https://bugs.launchpad.net/ubuntu/+source/xfwm4/+bug/978333

I do not think that this is a segfault, as there is no core dump in /var/crash, unless something catches the signal? If so, then it shouldn't, as Ubuntu has apport to detect and upload crashes.

In my case, this seems to be a result of shutdown failing. I click the shutdown button, nothing happens, I click it again and it says "Failed to receive a reply from the session manager. Session manager must be in idle state when requesting a shutdown."

xsession-errors shows:

(xfwm4:2042): libxfce4ui-WARNING **: ICE I/O Error

(xfwm4:2042): libxfce4ui-WARNING **: Disconnected from session manager.
** Message: using fallback from indicator to GtkStatusIcon
** Message: xfsm-shutdown-helper.c:1472: Using ConsoleKit to Stop

I think I have a reproducible test case:

* log in
* xfce loads panel, begins to restore session, loads firefox etc.
* while this is happening, click on shutdown action button in panel
* click on shutdown again
* Get dialog popup ("Failed to receive a reply from the session manager. Session manager must be in idle state when requesting a shutdown.")
* ctrl-alt-f1 (we somehow broke shutdown, and sometimes it stops and sometimes the system still shuts down, switching to the console seems to prevent consolekit from shutting down)

The system will now be in a state where there is a zombie xfce4-session process, and most other xfce processes that would normally be running (the ones with --sm-client-id in the args) are not running (including xfwm4)

However, there is a new xfce4-session process, and (this is a guess) perhaps it is now responsible for removing xfwm4 from the session.

Could this be caused by bug #5379 - "xfce session can't properly handle 2+ applications with interactive session save"?

The description there sounds the same as what I've seen ("Instead, it will wait 1 minute, and then forcibly close the session. During this period, a second logout attempt will say that the session manager must be idle when requesting shutdown.")

I wonder if this is what causes bug #8070 (xfwm4 not running on startup)?

Also see Launchpad https://bugs.launchpad.net/fedora/+source/xfwm4/+bug/978333 which links to bug reports on Fedora, Debian and Ubuntu

Launchpad +bug/978333 describes exactly what happens if xfsm fails on logout; the reason may or may not be an interact request. And yes, xfwm4 is not restarted on the next login (though it's easy to launch it manually).

Bug #8070 looks like something different to me.

Perhaps it is not so obvious from the title of bug #8070 that it is the same, but if you read the bug description, it is the symptoms of xfwm4 not being started. Four of the users on that bug also confirm that the cause is xfwm4 not being started, because it is no longer in the saved session file.

Apparently, xfwm4 not being started at login is the most frequently reported xfce bug in forums, but nobody has managed to track down the cause. I was just wondering if this bug might be that cause, as the symptoms (logout, "session manager must be idle" error, force close of session, no xfwm4) sound the same.

I saw this too. Installed a grub update via yum.
Logged out and got a shutdown fail.. may have clicked shutdown again.
After a minute or so it logged me out.
No window manager after logging in again.

A quick workaround for me was to
   mv .cache bad.cache
log out and back in again.

Created attachment 4565
xfce4-session-4.8.3-fix-logout-fail-with-multiple-interacts.patch

This patch should fix the issue. In my case, this is probably also the cause of bug #8070 (XFWM4 issues at startup).

Basically there are two issues in xfce4-session:
1) With >1 interacting clients, the already interacting client gets moved from state XFSM_CLIENT_INTERACTING -> XFSM_CLIENT_WAITFORINTERACT. This looks like a typo to me, I think the author meant to set the new client to state XFSM_CLIENT_WAITFORINTERACT instead.
2) The 60 second timer is not cancelled even though the client responded in time, so even though the client is waiting in state XFSM_CLIENT_WAITFORINTERACT, it gets timed out and disconnected.

Why does this remove xfwm4 from the session?

xfwm4 always seems to request interaction. If a second client requests interaction, xfwm4 gets moved out of state XFSM_CLIENT_INTERACTING. It then sends interact done and so xfce4-session kills it!

[1342903947] Client Id = 24469b94c-4060-4fb1-aafe-b747eefc7547, send INTERACT DONE, but client is not in INTERACTING state
   Client will be disconnected now.

Bang, no more xfwm4 in the session, the session gets saved, and on next login it doesn't get run.

(Really, this should also be fixed so that xfwm4 always gets started regardless of whether or not it's in the session - a crash of xfwm4 shouldn't cause the user to lose the window manager forever, most users will not know how to switch to a console and restart xfwm4 manually)

Please see bug #5379 for a fix for the issue that caused this problem in my case (xfwm4 getting removed from session file on logout due to two apps both requesting interaction).

The patch works for me, with 2 different interactive-save applications. Not sure if the original xfce4-session nukes any clients waiting for interaction on save cancelled (it's interaction is broken, as described in this bug report), but the patched version is OK. Let's hope it'll be applied in the foreseeable future.

(In reply to comment #8)

Thanks a lot. This patch works also for me (applies to xfce4 4.10/git HEAD 499a719019... (22.7.2012) in OpenSUSE 11.4). Hope it will be applied soon :-)

After some more testing, it seems that "with 4.8, even a single xsmp interact request may break the session logout" was not a precise description, at least for my system. A single program still works fine if, and only if, xfce "Prompt on logout" is turned off. Perhaps the 4.8 logout itself uses interact - it's a logical thing to do - and so 1 more application becomes too much. (And it may be that I had the prompt turned off in my 4.6, can't remember.)

But the patched version works in all cases. Thank you, Chris. With GNOME writing their own SM, and xfce broken, I was beginning to wonder if xsmp has any future.

> Perhaps the 4.8 logout itself uses interact

It's xfwm4: xfwm4 always requests an interact because it uses libxfce4ui, libxfceui always requests interact so that it can call a program specific handler that may interact (or not).

BTW, to see what is going on with xfce4-session you can set XFSM_VERBOSE=1 in .xinitrc (or whatever your setup uses). When xfce4-session is started, it checks for this environment variable and, if present, writes a debug log to ~/.xfce4-session.verbose-log

What concerns me after the tests is that, with "Save session on logout" turned off, xfce simply kill the clients. Shoudn't it send a SmSaveGlobal, so they can ask the user for any unsaved work? It's not really a "save session", since the client states will not be saved.

I know it's a bit insolent, but Chris, can you take a look at that? If it requires too much work, some directions on how to implement it would be enough.

BTW, I noticed this bug is "assigned" to <email address hidden>, and the QA is not reading bugmail. Perhaps one of us should contact him directly?

Can someone review the patch and maybe commit it to the repository?

> Shoudn't it send a SmSaveGlobal, so they can ask the user for any unsaved work?

I don't know - what do other desktops do? https://live.gnome.org/SessionManagement/NotesOnXSMP under section "SaveYourselfRequest (p. 6)" seems to echo your complaint:

"Session managers generally don't let the client decide whether or not to save the session when calling SaveYourselfRequest; they use a combination of preferences/settings and logout-dialog buttons to decide. In theory then, the session manager should just ignore the passed-in save-type, and set the save-type of the SaveYourself messages to SmSaveGlobal or SmSaveBoth depending on whether it's just shutting down, or also saving the state. This is what ksmserver does, but old-gnome-session and xfce-session are both buggy:

xfce-session only sends SaveYourselfs at all if the user chooses to save the session (in which case it sends the SaveYourselfs with the requested save-type); if the session is not being saved, it just skips over the SaveYourself phase entirely and goes directly to Die. (Technically, that violates the spec, although it violates it in a way that no client can detect, so it doesn't really matter.)

if you pass SmSaveGlobal to xfce-session, and the user chooses to save their state, then correctly-written clients will not save their state."

It looks like it would be possible to change the behaviour to match ksmserver as described above, from a quick look I'd guess it calls sm_save_yourself_request in sm-layer.c and then xfsm_manager_save_yourself_global in xfsm-manager.c, you probably just need to override save_type there and set it to SmSaveGlobal or SmSaveBoth just above the "if (!shutdown || shutdown_save) { shutdown with save } else { shutdown without save }" code.

*** Bug 7750 has been marked as a duplicate of this bug. ***

*** Bug 8196 has been marked as a duplicate of this bug. ***

xfwm4 was sometimes(rarely) terminating on startup, for me, and I had a focus follows mouse or something - fix was to restart startx.
The error is this (RenderBadPicture at the very end):
...
DBG[display.c:468] myDisplayGrabServer(): entering myDisplayGrabServer
DBG[display.c:475] myDisplayGrabServer(): grabs : 2
DBG[display.c:468] myDisplayGrabServer(): entering myDisplayGrabServer
DBG[display.c:475] myDisplayGrabServer(): grabs : 3
DBG[display.c:483] myDisplayUngrabServer(): entering myDisplayUngrabServer
DBG[display.c:495] myDisplayUngrabServer(): grabs : 2
DBG[display.c:483] myDisplayUngrabServer(): entering myDisplayUngrabServer
DBG[display.c:495] myDisplayUngrabServer(): grabs : 1
DBG[display.c:483] myDisplayUngrabServer(): entering myDisplayUngrabServer
DBG[display.c:491] myDisplayUngrabServer(): ungrabbing server
DBG[display.c:495] myDisplayUngrabServer(): grabs : 0
XError: BadDamage (invalid Damage parameter)
==> XID 0x600350, Request 143, Error 151 <==
XError: BadDamage (invalid Damage parameter)
==> XID 0x60034c, Request 143, Error 151 <==
XError: BadDamage (invalid Damage parameter)
==> XID 0x60034c, Request 143, Error 151 <==
XError: RenderBadPicture (invalid Picture parameter)
==> XID 0x5f, Request 139, Error 143 <==
DBG[main.c:701] main(): xfwm4 terminated

I am wondering if this recent commit fixed that 3f1b7c02ddcbb686f6f227b09f6e3017445880bf because I seem to be unable to reproduce it again, although it was rare/hard to reproduce anyway. So either that fixed it, or it's just that rare and hard to reproduce.

This is from another log (also pre that commit):
...
DBG[display.c:468] myDisplayGrabServer(): entering myDisplayGrabServer
DBG[display.c:471] myDisplayGrabServer(): grabbing server
DBG[display.c:475] myDisplayGrabServer(): grabs : 1
DBG[display.c:468] myDisplayGrabServer(): entering myDisplayGrabServer
DBG[display.c:475] myDisplayGrabServer(): grabs : 2
DBG[display.c:468] myDisplayGrabServer(): entering myDisplayGrabServer
DBG[display.c:475] myDisplayGrabServer(): grabs : 3
DBG[display.c:483] myDisplayUngrabServer(): entering myDisplayUngrabServer
DBG[display.c:495] myDisplayUngrabServer(): grabs : 2
DBG[display.c:483] myDisplayUngrabServer(): entering myDisplayUngrabServer
DBG[display.c:495] myDisplayUngrabServer(): grabs : 1
DBG[display.c:483] myDisplayUngrabServer(): entering myDisplayUngrabServer
DBG[display.c:491] myDisplayUngrabServer(): ungrabbing server
DBG[display.c:495] myDisplayUngrabServer(): grabs : 0
XError: BadDamage (invalid Damage parameter)
==> XID 0xa002c1, Request 143, Error 151 <==
XError: RenderBadPicture (invalid Picture parameter)
==> XID 0x5f, Request 139, Error 143 <==
DBG[main.c:701] main(): xfwm4 terminated

Olivier, if you could confirm whether or not that commit fixes this, I would appreciate it very much, save me some time. Otherwise, if you have any suggestions on getting better debug for that, I'd be happy to.

Thanks.

PS: the logs were made with at least commit e97066e3171564b513e8211ec39c26d8381adfc3 if not a more recent one

(In reply to EmanueL Czirai from comment #22)
> xfwm4 was sometimes(rarely) terminating on startup, for me, and I had a
> focus follows mouse or something - fix was to restart startx.
> The error is this (RenderBadPicture at the very end):
> [...]
> XError: RenderBadPicture (invalid Picture parameter)
> ==> XID 0x5f, Request 139, Error 143 <==
> DBG[main.c:701] main(): xfwm4 terminated
>
> I am wondering if this recent commit fixed that
> 3f1b7c02ddcbb686f6f227b09f6e3017445880bf because I seem to be unable to
> reproduce it again, although it was rare/hard to reproduce anyway. So either
> that fixed it, or it's just that rare and hard to reproduce.
> [...]
> Olivier, if you could confirm whether or not that commit fixes this, I would
> appreciate it very much, save me some time. Otherwise, if you have any
> suggestions on getting better debug for that, I'd be happy to.

Nope, none of the XError are fatal. The commit you point out is completely unrelated and purely cosmetic.

Besides, the fact that you see "xfwm4 terminated" means it died gracefully, i.e. it's not a crash.

Thanks Olivier, I'll investigate further.
The thing is, it only terminated when this message happened:

XError: RenderBadPicture (invalid Picture parameter)
==> XID 0x5f, Request 139, Error 143 <==
DBG[main.c:701] main(): xfwm4 terminated

When it doesn't terminate, there's no RenderBadPicture in the log, even though there are other many BadDamage ones.

I'll let you know if I find out anything. (should start a new bug(when I find something) ? because I think I was wrong to post here even though I thought the title matches my issue)

(In reply to EmanueL Czirai from comment #24)
> Thanks Olivier, I'll investigate further.
> The thing is, it only terminated when this message happened:
>
> XError: RenderBadPicture (invalid Picture parameter)
> ==> XID 0x5f, Request 139, Error 143 <==
> DBG[main.c:701] main(): xfwm4 terminated
>
> When it doesn't terminate, there's no RenderBadPicture in the log, even
> though there are other many BadDamage ones.

No, it's unrelated.

> I'll let you know if I find out anything. (should start a new bug(when I
> find something) ? because I think I was wrong to post here even though I
> thought the title matches my issue)

Correct, this bug is unrelated to your issue.