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 xfce-bugs@xfce.org.
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.
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.
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)
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 xfce-bugs@xfce.org, 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.
Thank you for the SmSave clues and the interesting link. I'll write to the QA for this bug directly.
Thanks for your work on this Chris, could you please integrate the fix you speak of (saving clients willing to interact without having checked saving the whole session) in this patch? You seem to have this figured out and it would be great if this could be fixed once and for all. Thanks in advance, Jérôme
Hi, I don't have systemd so I can't test your patch. Reviewing your patch, you should respect the naming conventions of xfce4-session. It would be great for readability and maintainability if you used the same file structure and naming conventions as the xfsm-consolekit.{c,h} files. Regards, Jérôme
(In reply to comment #19) > Hi, > > I don't have systemd so I can't test your patch. > > Reviewing your patch, you should respect the naming conventions of > xfce4-session. It would be great for readability and maintainability if you > used the same file structure and naming conventions as the > xfsm-consolekit.{c,h} files. > > Regards, > > Jérôme Wrong bug report sorry...
Actually I asked Chris for SmSaveGlobal when "Save session on logout" is off, and he gave me some directions, so here is the patch. It was a bit more work than I expected, because when sending SmsSaveYourself to the clients, xfsm itself receives one and saves the session. So I had to add a save_session variable to XfsmManager, and use xfsm_manager_perform_shutdown from xfsm_manager_complete_saveyourself. Whoever is interested, please test: (a) if xfce saves the xsmp clients (for example gedit) and the legacy clients (for example xfce Terminal) when "Save session on logout" is on, and does not save them when off; (b) if gedit (or another xsmp client) asks to save any modified files when "Save session on logout" is off. How to check: patch and compile xfce4-session, replace /usr/bin/xfce4-session with xfce4-session-$ver/xfce4-session/.libs/xfce4-session, logout and re-login.
Created attachment 4577 Chris patch, plus SmSaveGlobal if "Save session on logout" is off
(In reply to comment #21) > [...] > Whoever is interested, please test: here .. me .. i am interested! I have Xfce 4.10 on Opensuse 11.4. I applied the patch manually (sorry for that) to git head (2c25a261a8e..., file xfsm-manager.c is unchanged from 4.10.0). Great work, mostly good :-) > > (a) if xfce saves the xsmp clients (for example gedit) and the legacy > clients (for example xfce Terminal) when "Save session on logout" is on, and > does not save them when off; gedit: yes, it works as expected. (last opened file restored, if session saved. If not session saved, last saves session gets restored. gedit asks on onchanged files. cancel works. ) Terminal: yes, it works as expected. (Terminal remember it's last directory, if session saves. It does not, if session is not saved.) > > (b) if gedit (or another xsmp client) asks to save any modified files when > "Save session on logout" is off. gedit asks, but "cancel logout" does NOT cancel the logout. > > How to check: patch and compile xfce4-session, replace > /usr/bin/xfce4-session with > xfce4-session-$ver/xfce4-session/.libs/xfce4-session, logout and re-login. Done. Thanks :-)
Yes, I went a bit too far. Here's a fixed version.
Created attachment 4582 Chris patch, plus SmSaveGlobal on logout without session save (a)
(In reply to comment #25) > Created attachment 4582 > Chris patch, plus SmSaveGlobal on logout without session save (a) perfect - works fine for me :-) (OpenSuSE 11.4, "X11:/xfce"-repository with XFCE 4.10, compiled with git head where xfsm-manager.c is unchanged since tag "xfce4-session-4.10.0") tested: gedit+Terminal with "SAVE SESSION" and gedit "cancel logout" => ok gedit+Terminal with "DO NOT SAVE SESSION" and gedit "cancel logout" => ok gedit+Terminal with "SAVE SESSION" and gedit "save" => ok gedit+Terminal with "DO NOT SAVE SESSION" and gedit "save" => ok (Terminal is legacy xsm-client, gedit a "new" xsm client.)
Hello, Sorry for the delay, I finally found some time to review your patch (https://bugzilla.xfce.org/attachment.cgi?id=4582). Unfortunately, it does not work as good for me. When I have save session off and try to log out with a text editor open, I'm prompted to save my work which is correct but then the text editor is restored on the next login. I think this is not correct, the work should be saved but the editor not restored (ie. SmSaveGlobal and not SmSaveBoth right?). I think this has to do with the way you set manager->save_session, I fail to see the logic behind that, could you explain it please?
Ok, after more digging, this only happens when using the xfce4-panel actions plugin, with xfce4-session-logout, it works as advertised. And I got the save_session logic, looks right in fact. I'll dig the xfce4-panel issue before committing this.
Ok, pushed to git master branch. The issue I had is in fact bug #8678, the option is not respected by the actions plugin. If no bug is reported against this code in the near future, I'll backport it to the stable branch as it should fix a fair number of annoyances and avoids data loss in some cases.
*** Bug 8934 has been marked as a duplicate of this bug. ***
*** Bug 8981 has been marked as a duplicate of this bug. ***
(In reply to comment #29) > Ok, pushed to git master branch. The issue I had is in fact bug #8678, the > option is not respected by the actions plugin. > > If no bug is reported against this code in the near future, I'll backport it > to the stable branch as it should fix a fair number of annoyances and avoids > data loss in some cases. Did you had a chance to work on the backport?
A 4.10.1 release and/or a 4.8.x backport would be welcome here. :) We see a number of folks hit this in Fedora land. ;(
To those asking for a backport: the patch already applies cleanly to xfce4-session-4.8.3
(In reply to comment #34) > To those asking for a backport: the patch already applies cleanly to > xfce4-session-4.8.3 It doesn't apply cleanly, although there's only two rejected hunks which seem easy to fix. I'll try to test the patch against 4.8 and see if it works.
It applies cleanly to the released debian/ubuntu upstream source for their version 4.8.3: $ wget http://ftp.debian.org/debian/pool/main/x/xfce4-session/xfce4-session_4.8.3.orig.tar.bz2 $ wget --no-check-certificate -O xfce4-session.patch https://bugzilla.xfce.org/attachment.cgi?id=4582 $ tar -jxvf xfce4-session_4.8.3.orig.tar.bz2 $ cd xfce4-session-4.8.3 $ patch -p0 < ../xfce4-session.patch It also applies cleanly to the post-patched version (apt-get source xfce4-session). Shouldn't that be enough for inclusion into those distros?
Cherry-picked the fix in the xfce-4.8 and xfce-4.10 branches.
*** Bug 8681 has been marked as a duplicate of this bug. ***
*** Bug 7687 has been marked as a duplicate of this bug. ***
*** Bug 8372 has been marked as a duplicate of this bug. ***
*** Bug 8706 has been marked as a duplicate of this bug. ***
*** Bug 7750 has been marked as a duplicate of this bug. ***
*** Bug 8196 has been marked as a duplicate of this bug. ***