Created attachment 2240 snapshot of ~/.cache/sessions I seem to be continually getting myself into a situation where xfce4-session tries to launch 100+ instances of xfdesktop on login. Attached is gzipped ~/.cache/sessions folder. The only thing I can think of is that I have the "Automatically save session on logout" activated. In order to try to troubleshoot this on my end, I've nuked ~/.config so I don't have that folder to go with that set of sessions. If it happens again, I'll add it. I'm using Xfce 4.6 on Ubuntu Jaunty.
I've had one report of this under Fedora as well... not sure how it's happening.
*** Bug 4764 has been marked as a duplicate of this bug. ***
Unfortunately, I kept having severe issues with the intel driver in jaunty. I decided to move back to hardy for now, so I don't have xfce 4.6 available to test right now. I can getting a virtual machine up and running if you want, though.
I am observing almost identical behaviour on my machine. If you need any clues, I am happy to provide them.
This bug has been reported on Ubuntu Launchpad as: https://bugs.launchpad.net/bugs/329616 A recent upgrade (two-three days ago), resulted in the following problem: 1. XFCE session starts with flickering icons on desktop and multiple windows (attached) showing message "Unable to contact the Xfce Trash service." 2. Dozens (sometimes over 50) copies of xfdesktop process are started (see attached output of ps). Killing all those xfdesktop processes results in absence of desktop wallpaper and icons, but at least the computer becomes usable. I also tried eliminating all but one xfdesktop entries in XFCE session configuration (Xfce4 Settings Manager -> Session and Startup -> Session tab), but on next login the same multiple xfdesktop processes are started again. It is happening in Xubuntu Jaunty 9.04 with Xfce 4.6.0
I just went through this problem of waaay too many xfdesktops but it was most likely my own doing. I would like to have a wallpaper image that changes every xx minutes. I researched and found that a 'killall -USR1 xfdesktop' should get a new wallpaper. The USR1 didn't work but HUP did. So I used it. (xfdesktop --reload should also get a new desktop but it doesn't seem to work) But upon a system reboot a week later, I got about 1400+ xfdesktops. And the machine was dead. Finally deleted ~/.cache/sessions/xfce4-session-linux1:0 and restarted xfce and that took care of the problem. And I won't be using HUP in the future.
still present in current karmic with xfdesktop 4.6.1-1 this causes serious trouble as it makes the computer unusable for long periods of time platform above is set to 64-bit, I just wanted to add that I run a 32-bit system.
Created attachment 2884 xfce4 session files from .cache I hit it again. I had to move xfdesktop and killall it. I still have my session as it was, so I can try to provide any info. This is my xfce4 session from .cache/session and a .bak file from it.
In both sessions, the duplicate xfdesktop entries _always_ have the same client id in the restart command, which differs from the client id property. Both client ids should be the same as far as I understand the specs, and this is true for other entries in the session.
Hmm, since the SessionClient from gui4 which 4.6.1 use is obsolete, debugging this issue on the 4.6.1 code is not worth it. I'll try to port xfdesktop to the 4ui session client.
Having a fix for 4.6 would be nice too, since in 4.6 the gui4 client was used. I have a hypothesis how this mess propagated, but I haven't yet figured out how it is triggered in the first place. First notice how the --sm-client-id parameter in the troublesome session files are all the same. In the first session file it's definitely an invalid id. Xfdesktop passes this on to the gui4 SessionClient (SC). The SC will attempt to register with this client id. Since it is invalid, the SM will generate a new one, and return it. The SC receives this id, and uses it to decide in what state it is, but then discards it. The point is, the new and valid id is _not_ used for the restart command. Thus the old, and invalid client id remains. So when the user logs in again, the SM will start xfdesktop with the invalid id. Upon start, xfdesktop actually creates a _new_ registration with the SM, because of the invalid id, instead of reusing the previous entry as it is supposed to. From here on I'm not sure. Does the SM think that the start-up of xfdesktop failed, because xfdesktop never registered with the client id it expected? I'll have to investigate some more. Also I still don't know how the invalid id came into being in the first place.
I added bug 6317 for gui4.
I just helped a user on irc who had this issue, so I was able to gather a bit more data. The guy had slow login times, and his session file contained 31 instances of xfdesktop. Again the client id's of the restart command were always the same. At this time he had 7 instances of xfdesktop running in parallel. After logging in and out (I don't know how many times, 2-3) he had 37 xfdesktop instances in the session file, and 11 running in parallel. The client id in the session file's restart commands was the same. 'killall xfdesktop' did not reduce this count at all, the session manager restarted all of these instances. 'xfdesktop --quit' would quit one instance, and repeated executions had no effect.
Reassign to xfce-bugs@xfce.org.
*** Bug 4014 has been marked as a duplicate of this bug. ***
I've gotten a few more reports of this happening with 4.8 now. In these cases the users do not save the session on logout (they want to wipe the session and start from default next time they login). I wonder if this is this same issue, or a different one in this case. Were other folks not saving session on logout and possibly getting a messed up session on next login? (I can file a seperate bug for this if this is not actually related here).
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/xfce4-session/-/issues/3. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev