Bug 442380

I think I might have the same issue, if by desktop you mean monitor.  I have multiple systems and each has three monitors, and upon login the applications generally start on the wrong monitor with different sizes than the ones I saved.

Session restore had progressively gotten better until about the Fedora 31-32 era when I would pretty consistently get perfect session restoration at login.  But after I updated to F34 (still using X11) it suddenly got much worse.

If there's any information on how I might be able to debug session restore I'd be happy to try.  It's not a deal breaker but it gets annoying to have to drag and resize 10-15 windows back into position whenever I login.

whatever whoever has done, after update to

Operating System: Fedora 34
KDE Plasma Version: 5.22.5
KDE Frameworks Version: 5.86.0
Qt Version: 5.15.2
Kernel Version: 5.13.19-200.fc34.x86_64 (64-bit)
Graphics Platform: X11

it's working as before. all state remembered properly. for me, this is gone.

I saw one perfect restore after updating to that version as well, but my next login had the same jumbled session restore.  My one good restore was just after a reboot but I don't see how that could really matter.

unfortunately, not solved.

i did following update:
---------------
Begin time     : Mon 27 Sep 2021 03:09:19 PM CEST
Begin rpmdb    : 4143:f6d07c812925509734e4deebc6de9ef67339f1eb
End time       : Mon 27 Sep 2021 03:09:30 PM CEST (11 seconds)
End rpmdb      : 4143:5d77b77f1147d297910e976e96a9a9b254fdf577
Return-Code    : Success
Releasever     : 34
Command Line   : -y upgrade --refresh --nogpgcheck --allowerasing
Comment        :
Packages Altered:
    Upgrade  bind-libs-32:9.16.21-1.fc34.x86_64      @updates
    Upgraded bind-libs-32:9.16.20-3.fc34.x86_64      @@System
    Upgrade  bind-license-32:9.16.21-1.fc34.noarch   @updates
    Upgraded bind-license-32:9.16.20-3.fc34.noarch   @@System
    Upgrade  bind-utils-32:9.16.21-1.fc34.x86_64     @updates
    Upgraded bind-utils-32:9.16.20-3.fc34.x86_64     @@System
    Upgrade  python3-bind-32:9.16.21-1.fc34.noarch   @updates
    Upgraded python3-bind-32:9.16.20-3.fc34.noarch   @@System
    Upgrade  plasma-desktop-5.22.5-4.fc34.x86_64     @zawertun-kde
    Upgraded plasma-desktop-5.22.5-3.fc34.x86_64     @@System
    Upgrade  plasma-desktop-doc-5.22.5-4.fc34.noarch @zawertun-kde
    Upgraded plasma-desktop-doc-5.22.5-3.fc34.noarch @@System
[root@chlnx2 ~]#
---------------
after reboot, it has been working, twice (reboots in between).

then i did only these updates
---------------
Begin time     : Fri 01 Oct 2021 05:14:04 PM CEST
Begin rpmdb    : 4143:d3501c1eb4f2c50e97a2eab5d4734705cbd46066
End time       : Fri 01 Oct 2021 05:14:31 PM CEST (27 seconds)
End rpmdb      : 4143:c1d56fd3be640c1bd2219618cc9c90e13b851b03
Return-Code    : Success
Releasever     : 
Command Line   : 
Comment        : 
Packages Altered:
    Upgrade  cifs-utils-6.13-3.fc34.x86_64               @updates
    Upgrade  cifs-utils-info-6.13-3.fc34.x86_64          @updates
    Upgrade  flatpak-1.10.3-1.fc34.x86_64                @updates
    Upgrade  flatpak-libs-1.10.3-1.fc34.x86_64           @updates
    Upgrade  flatpak-selinux-1.10.3-1.fc34.noarch        @updates
    Upgrade  flatpak-session-helper-1.10.3-1.fc34.x86_64 @updates
    Upgraded cifs-utils-6.11-3.fc34.x86_64               @@System
    Upgraded cifs-utils-info-6.11-3.fc34.x86_64          @@System
    Upgraded flatpak-1.10.2-4.fc34.x86_64                @@System
    Upgraded flatpak-libs-1.10.2-4.fc34.x86_64           @@System
    Upgraded flatpak-selinux-1.10.2-4.fc34.noarch        @@System
    Upgraded flatpak-session-helper-1.10.2-4.fc34.x86_64 @@System
[root@chlnx2 ~]#
---------------
Begin time     : Fri 01 Oct 2021 12:36:03 AM CEST
Begin rpmdb    : 4143:0787bdfaa5c01dcaa45430e9dc56f2dc620d5768
End time       : Fri 01 Oct 2021 12:36:36 AM CEST (33 seconds)
End rpmdb      : 4143:d3501c1eb4f2c50e97a2eab5d4734705cbd46066
Return-Code    : Success
Releasever     : 34
Command Line   : -y upgrade --refresh --nogpgcheck --allowerasing
Comment        : 
Packages Altered:
    Upgrade  createrepo_c-0.17.5-1.fc34.x86_64                     @updates
    Upgraded createrepo_c-0.17.3-1.fc34.x86_64                     @@System
    Upgrade  createrepo_c-libs-0.17.5-1.fc34.x86_64                @updates
    Upgraded createrepo_c-libs-0.17.3-1.fc34.x86_64                @@System
    Upgrade  darktable-3.6.1-1.fc34.x86_64                         @updates
    Upgraded darktable-3.6.0-2.fc34.x86_64                         @@System
    Upgrade  firefox-92.0.1-1.fc34.x86_64                          @updates
    Upgraded firefox-92.0-2.fc34.x86_64                            @@System
    Upgrade  jitterentropy-3.3.0-1.fc34.x86_64                     @updates
    Upgraded jitterentropy-3.0.2-2.git.409828cf.fc34.x86_64        @@System
    Upgrade  libicu-67.1-7.fc34.x86_64                             @updates
    Upgraded libicu-67.1-6.fc34.x86_64                             @@System
    Upgrade  libicu-devel-67.1-7.fc34.x86_64                       @updates
    Upgraded libicu-devel-67.1-6.fc34.x86_64                       @@System
    Upgrade  libmediainfo-21.09-1.fc34.x86_64                      @updates
    Upgraded libmediainfo-21.03-1.fc34.x86_64                      @@System
    Upgrade  libssh-0.9.6-1.fc34.x86_64                            @updates
    Upgraded libssh-0.9.5-2.fc34.x86_64                            @@System
    Upgrade  libssh-config-0.9.6-1.fc34.noarch                     @updates
    Upgraded libssh-config-0.9.5-2.fc34.noarch                     @@System
    Upgrade  mediainfo-21.09-1.fc34.x86_64                         @updates
    Upgraded mediainfo-21.03-1.fc34.x86_64                         @@System
    Upgrade  mediainfo-gui-21.09-1.fc34.x86_64                     @updates
    Upgraded mediainfo-gui-21.03-1.fc34.x86_64                     @@System
    Upgrade  perl-Module-CoreList-1:5.20210920-1.fc34.noarch       @updates
    Upgraded perl-Module-CoreList-1:5.20210820-1.fc34.noarch       @@System
    Upgrade  perl-Module-CoreList-tools-1:5.20210920-1.fc34.noarch @updates
    Upgraded perl-Module-CoreList-tools-1:5.20210820-1.fc34.noarch @@System
    Upgrade  perl-libwww-perl-6.57-1.fc34.noarch                   @updates
    Upgraded perl-libwww-perl-6.56-1.fc34.noarch                   @@System
    Upgrade  php-cli-7.4.24-1.fc34.x86_64                          @updates
    Upgraded php-cli-7.4.23-1.fc34.x86_64                          @@System
    Upgrade  php-common-7.4.24-1.fc34.x86_64                       @updates
    Upgraded php-common-7.4.23-1.fc34.x86_64                       @@System
    Upgrade  pinentry-1.2.0-1.fc34.x86_64                          @updates
    Upgraded pinentry-1.1.1-3.fc34.x86_64                          @@System
    Upgrade  pinentry-gtk-1.2.0-1.fc34.x86_64                      @updates
    Upgraded pinentry-gtk-1.1.1-3.fc34.x86_64                      @@System
    Upgrade  pinentry-qt-1.2.0-1.fc34.x86_64                       @updates
    Upgraded pinentry-qt-1.1.1-3.fc34.x86_64                       @@System
    Upgrade  python-systemd-doc-234-19.fc34.x86_64                 @updates
    Upgraded python-systemd-doc-234-16.fc34.x86_64                 @@System
    Upgrade  python2.7-2.7.18-15.fc34.x86_64                       @updates
    Upgraded python2.7-2.7.18-11.fc34.x86_64                       @@System
    Upgrade  python3-systemd-234-19.fc34.x86_64                    @updates
    Upgraded python3-systemd-234-16.fc34.x86_64                    @@System
    Upgrade  rng-tools-6.14-1.git.56626083.fc34.x86_64             @updates
    Upgraded rng-tools-6.13-2.git.d207e0b6.fc34.x86_64             @@System
    Upgrade  selinux-policy-34.21-1.fc34.noarch                    @updates
    Upgraded selinux-policy-34.20-1.fc34.noarch                    @@System
    Upgrade  selinux-policy-targeted-34.21-1.fc34.noarch           @updates
    Upgraded selinux-policy-targeted-34.20-1.fc34.noarch           @@System
    Upgrade  squashfs-tools-4.5-3.20210913gite048580.fc34.x86_64   @updates
    Upgraded squashfs-tools-4.5-2.fc34.x86_64                      @@System
    Upgrade  switchboard-plug-networking-2.4.1-1.fc34.x86_64       @updates
    Upgraded switchboard-plug-networking-2.4.0-1.fc34.x86_64       @@System
    Upgrade  tzdata-2021b-1.fc34.noarch                            @updates
    Upgraded tzdata-2021a-1.fc34.noarch                            @@System
    Upgrade  tzdata-java-2021b-1.fc34.noarch                       @updates
    Upgraded tzdata-java-2021a-1.fc34.noarch                       @@System
    Upgrade  wayland-protocols-devel-1.23-1.fc34.noarch            @updates
    Upgraded wayland-protocols-devel-1.21-1.fc34.noarch            @@System
[root@chlnx2 ~]#
---------------
and the bad behavior was back. all windows on first screen again. what's happening here?

=> i will roll back these updates and report back.

regards,
Petr.

(ok, not possible to rollback, because most of the previous packages already purged from repo)

Petr, this happened because the upgrade made Wayland the default display server for you, and while this issue is fixed on X11, it's still broken on Wayland. That is tracked with Bug 421870; let's continue there.

Just a note that I have always been running X11, and the issue does not appear to be fixed there (for me at least).  As I noted previously, I managed one perfect session restore but then haven't been able to repeat it.

Hmm, maybe it is still an issue then.

hello Nate,
sorry, but me too, i have to disagree. i always was running X11 (also because Wayland does not run on any of my servers). no, not fixed in X11.
regards,
Petr.

I should add (in case it somehow matters) that I am still running good old KDM as a display manager.  As far as I know it won't even start a Wayland session without some kind of hacking, which I haven't done.

In any case, if there's anything I can do to debug things, I would be happy to try.  I don't know the source tree well but I'm capable of tracing, tweaking settings or applying patches and rebuilding things if I'm pointed in the right direction.

Just upgraded from Fedora 34 to Fedora 35.  Plasma 5.23.3 for Fedora 35 installed. Had to reboot to pick up new kernel. The first boot seem to restore the applications to the proper virtual desktop. In subsequent logout/login  the old behaviour appeared.  Deleted all the files in .config/session/ and after a logout/login the correct behaviour appeared but a subsequent logout/login showed the incorrect behaviour. Repeated  several times with the same result.  I did absolutely nothing between the first and second logout/login sequences.

Since I made no other changes,  either the session save  process messes up the files in .config/session or the restore process is unable to work with the new files.  I assume that whoever is working on this has some way to verify the .config/session files.

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

Always seems to fail now even if I delete files in .config/session

Hi
just a small note to confirm I have the same problem : session is not correctly restored on next login, most of the windows are opened on the same virtual screen (not necesarily screen #1, could be #4 in my case (I have 6 virtual screen)
Happens for me since approx april 2021 when I updated my PC (mageia cauldron) to plasma 5.21
This is 100% reproductible, session is not restored correctly anymore since this update, while it worked flawlessly before (plasma < 5.21)

This is only with X11, I never used wayland.

Similar issue were also reported here https://bugzilla.redhat.com/show_bug.cgi?id=1956916 in case it can help

Thanks for any fix that could happen for this, it's a real pain when you need to manually move all your windows / apps on their expected virtual screen each time you power on your pc.

Try deleting the files in .config/session and then logout/login.

Do the logout/login twice and check after each.

(In reply to Brian Kaye from comment #15)
> Try deleting the files in .config/session and then logout/login.

Hi,

thanks for this hint. It works for me so far. I will check again tomorrow. Hopefully it is still going to work then.
By the way I have found more than 3600 files in the folder "~/.config/session". Wow, not bad, is it?

Operating System: Fedora 34
KDE Plasma Version: 5.22.5
KDE Frameworks Version: 5.85.0
Qt Version: 5.15.2
Kernel Version: 5.15.13-100.fc34.x86_64 (64-bit)
Graphics Platform: X11
Processors: 8 × Intel® Core™ i7-4770T CPU @ 2.50GHz
Memory: 7.2 GiB of RAM
Graphics Processor: Mesa DRI Intel® HD Graphics 4600

Problem persists in Fedora 35. System seems to keep older versions of the application files in .config/session. What surprises me is that more people are not complaining about this problem. That suggests that the problem is related to something in my setup. It occurs even if I create a new user.     

I really need to know what the configuration files .config/session mean. I suspect one of the developers has a test program to read those files and verify what they should do. If the files are correct then the restore process is at fault.

(In reply to Brian Kaye from comment #18)
> Problem persists in Fedora 35. System seems to keep older versions of the
> application files in .config/session. 

In my case the folder "config" contains more than 3500 files of "KWrite_......." which were created in a period from December 2019 to December 2021. Usually I have 5 to 15 instances of KWrite running when I logout.

cleaning up the .config/sessions directory seems to have done it. there must have been some entries there, which prevented the session restore. deleting everything a redoing the whole application spread over all the screens/desktops from scratch now survived several reboots. i'm pretty confident ...
esp the dolphin and kate/kwrite windows they still exhibit some resistance to properly restore. now they show up on the correct dektop, but have strange sizes. it would be useful to know, in which file(s) the restore-sizes and restore-directories/files are kept. i could not find out, they're not in sessions.

(In reply to Brian Kaye from comment #18)
> Problem persists in Fedora 35. System seems to keep older versions of the
> application files in .config/session. What surprises me is that more people
> are not complaining about this problem. That suggests that the problem is
> related to something in my setup. It occurs even if I create a new user.     
> 
> I really need to know what the configuration files .config/session mean. I
> suspect one of the developers has a test program to read those files and
> verify what they should do. If the files are correct then the restore
> process is at fault.
I'm wondering the same ; isn't there some debug flag that could be enabled somewhere before kde/plasma start so that we could maybe see some meaningful message about what is happening when session is "restored" ?

if you do a strings command on /usr/bin/startplasma-x-11 you find a reference to 

startplasma-x11-5.23.4-1.fc35.x86_64.debug but I can't find it. That might have something relevant????

(In reply to Brian Kaye from comment #22)
> if you do a strings command on /usr/bin/startplasma-x-11 you find a
> reference to 
> 
> startplasma-x11-5.23.4-1.fc35.x86_64.debug but I can't find it. That might
> have something relevant????
debug packages/rpm are different, they contain all the symbols from the original source files, which is very useful when you get a core dump and want to load it from gdb to get the context at the time of the crash.
For this session issue, I was thinking about some runtime env variables that could be set before kde starts to get more verbose logs for example, but it's not sure at all that ksmserver (or whatever part parses the session config) has such log capability.
Anyway, let's see if someone from kde/plasma team can reproduce this.

Am  having a quick look at <https://develop.kde.org/docs/session-managment/>

(In reply to Petr from comment #20)
> cleaning up the .config/sessions directory seems to have done it. there must
> have been some entries there, which prevented the session restore. deleting
> everything a redoing the whole application spread over all the
> screens/desktops from scratch now survived several reboots. i'm pretty
> confident ...
> esp the dolphin and kate/kwrite windows they still exhibit some resistance
> to properly restore. now they show up on the correct dektop, but have
> strange sizes. it would be useful to know, in which file(s) the
> restore-sizes and restore-directories/files are kept. i could not find out,
> they're not in sessions.

well, i just experienced a set back. i can clean the sessions-dir, can re-set all apps, reboot and kde is remembering fine. then i continue working for some hours, shut down normally and after the next boot, all mis-behaviour is back. all windows cluttered up on first desktop. i do not understand this.

Just ran another set of simple tests with empty ~/.config/session.
1. empty session (nothing open except applets in bottom panel) then logout/login.
2. opened konsole session on desktop 2 ( of 4)
3. after logout/login konsole session ended  up in desktop 2 as expected
4. immediate logout/login konsole session ended up in desktop 1 

I repeated this test a couple of times with the same result  

If possible could someone repeat this test.

Three days ago I have deleted all the files in the folder "session" and it worked, but now it doesn't.
I have found more than 230 files within three days.

Files are added to .config/session every time you logout or restart except 'kwin_saved at previous logout_'. which appears to be replaced.  There seems to be another file involved .config/ksmserverrc. This file has the same timestamp as the 'kwin_saved at previous logout_' and there are references to the files in .config/session.

Wondered what programs were accessing  .config/session files. 
1. added  audit rule   with auditctl -w /home/******/.config/session -K SESSION
2. restarted the auditd daemon
3. started applications in a couple of desktops 
4. emptied /var/log/audit/audit.log
5. cleared files in .config/session
6. logout/login
7. windows did not open in correct desktops
8 . in a konsole window  ran ausearch -k SESSION --format text
There are a number of applications which are involved, kwin_x11, systemsettings5, konsole (looking at konsole files in.config/session

More confused. Woder if its some sort of race condition.

Forgot  to mention the "-p war" parameter on the auditctl command

It also happens to me on the laptop, on the PC and on a mini PC. On every reboot I have to sort the windows of each virtual desktop because they are stacked. Specifically, the dolphin windows are stacked and the rest, like konsole or kwrite are in different places. I have tried deleting the session files and although at first it seems to work then it fails again.

What linux distribution are you using? How many virtual desktops. I have found that deleting the .config/session files sometime corrects the problem for  one or several login/logouts or not at all. 

Dolphin also  adds an entry "dolphin_dolphin_dolphin" in .config/session when a dolphin window is closed. It seems to be used when dolphin is restarted.

The question still remains is why more people are not having this problem.  

According to the bug report this problem is assigned to "David Edmunson" . Sure wish we could get some suggestions from him.

I did report this problem on the Fedora bug list  <https://bugzilla.redhat.com/show_bug.cgi?id=1956916> on 2021-05-04. It might help if the people who have this problem tell us which distribution they are using.

(In reply to Brian Kaye from comment #32)
> What linux distribution are you using? How many virtual desktops. I have
> found that deleting the .config/session files sometime corrects the problem
> for  one or several login/logouts or not at all. 
> 
> Dolphin also  adds an entry "dolphin_dolphin_dolphin" in .config/session
> when a dolphin window is closed. It seems to be used when dolphin is
> restarted.
> 
> The question still remains is why more people are not having this problem.  
> 
> According to the bug report this problem is assigned to "David Edmunson" .
> Sure wish we could get some suggestions from him.

Sure, more information is better

I use Arch linux on all my computers, on the mini PC I have 4 virtual desktops, on the laptop I have 9 virtual desktops and on the PC 16 .

I have noticed that on every reboot the stacked dolphin windows are all the same size and each time the stack of windows is in a different place, it may have to do with the position of the last window you moved before the reboot.

Session restore had always worked fine until a couple of months ago, I don't remember the exact date but I remember it was when they announced that they had improved restoring the position of windows when you disconnect a second monitor, this may be a good starting point to find the bug.

What is restored correctly is in which virtual desktop each window belongs.

Because I work in several fields at the same time, I am very used to session restore, this is the main reason why I haven't switched to wayland. 

Thanks to all of you who are working on fixing these bugs, anything you need me to check or make a change to check if it works, I am at your disposal.

So its not just a Fedora issue. If you create a new user with some virtual desktops does the problem persist?  Just add the virtual desktops , start  an app in virtual desktop 2 and logoff/logon a couple of times. 

Like you it just seemed to stop working and I didn't really note when it started. 

I am increasingly frustrated at the lack of any acknowledgement from the KDE folks. I have contemplated switching away from KDE

The issue with the dolphin restarts may have something with the dolphin_dolphin_dolphin file in .config/session. That file seems to be updated when dolphin is closed and started again. It may be a separate but related issue if multiple dolphin windows are restarted at incorrect size(s).

I have noted in the past that Firefox is restarted in the correct window. Since I don't use it often ( I use waterfox) , I did not notice if it was the correct size.

(In reply to Brian Kaye from comment #36)
> The issue with the dolphin restarts may have something with the
> dolphin_dolphin_dolphin file in .config/session. That file seems to be
> updated when dolphin is closed and started again. It may be a separate but
> related issue if multiple dolphin windows are restarted at incorrect size(s).
> 
> I have noted in the past that Firefox is restarted in the correct window.
> Since I don't use it often ( I use waterfox) , I did not notice if it was
> the correct size.

Confirmed, it's a dolphin issue. I have done what you said to create a new user and open several applications on different desktops and the only windows that have the problem are the dolphin windows.

I thought it also happened with konsole and kwrite but it was because when you disconnect a second monitor the windows are not in the same place they were before.

Based on the contents of the .config/ksmserverrc file it looks like the previous versions of files in .config/session should be deleted at login because there is a "rm" command in the ksmserverrc file. 

"discardCommand2[$e]=rm,$HOME/.config/session/systemsettings_106d617273000164348968600000036930008_1643493938_600324

But the audit trace shows that the file deletion fails. So perhaps that is why  there seems to be a buildup of old files in .config/session. Maybe it is a separate bug. If we could find someone who has the file buildup problem but not the session restore problem (this bug) it would tell us its a separate problem.

My previous comment does not apply to the file "dolphin_dolphin_dolphin" The file seems  to be used to define the configuration of  dolphin when a new dolphin  window is opened to look like the one that was last closed( settings related).

for those that want to see this bug, one possible solution is to boot from an USB key live iso of Fedora 35 KDE
https://spins.fedoraproject.org/kde/download/index.html

from there you can boot into kde , set number of virtual desktops to 4 for example and change "startup and shutdow" / "desktop session" to "restore previous saved session"

then start konsole on virt #1, start firefox on virt #2 , start another konsole on virt #3 (with different size/position)
logout  then login again (press "enter" for password) and see if the sessions is restored or not.
most of the time I see that only firefox is restored on the correct virtual desktop. konsole's on the opposite are not restored.
but .config/session is created nevertheless, as well as "kwin_saved at previous logout"

so it might be a good way to reproduce the session bug on each time and maybe some kde dev could have a look.

Have you tried this? If the bug appears with this method then the bug is more pervasive than the number who have responded to this bug report. It might be a worthwhile test to use plasma-wayland instead of X11.

(In reply to Nicolas Pomarede from comment #40)
> for those that want to see this bug, one possible solution is to boot from
> an USB key live iso of Fedora 35 KDE
> https://spins.fedoraproject.org/kde/download/index.html
> 
> from there you can boot into kde , set number of virtual desktops to 4 for
> example and change "startup and shutdow" / "desktop session" to "restore
> previous saved session"
> 
> then start konsole on virt #1, start firefox on virt #2 , start another
> konsole on virt #3 (with different size/position)
> logout  then login again (press "enter" for password) and see if the
> sessions is restored or not.
> most of the time I see that only firefox is restored on the correct virtual
> desktop. konsole's on the opposite are not restored.
> but .config/session is created nevertheless, as well as "kwin_saved at
> previous logout"
> 
> so it might be a good way to reproduce the session bug on each time and
> maybe some kde dev could have a look.

important note : on the login screen you need to choose "plasma x11" and not the default "plasma wayland" in the bottom left, because session management is known to be broken under wayland.
but if you choose "plasma x11" then "restore previous saved session" you will see that all konsoles are opened on Virt #1 instead of their expected location.

So, this is a 100% reproductible case of loss of session info with plasma + X11

After reading through the comments above. I deleted all files from  ~/.config/session, and logged out, and then back in.

This is a test using KDE and X11.

I have two monitors with 9 different Activites defined. EVERYTHING ended up in the first Activity. I typically run my system for weeks at a time, because of this problem, with having to reposition all my returning windows, and restarting all the ones that don't reappear.

[xmas@reindeer ~]$ date
Mon Jan 31 06:51:04 PM CST 2022
[xmas@reindeer ~]$ cd ~/.config/session/
[xmas@reindeer session]$ ls -l
total 236
-rw-------. 1 xmas xmas   905 Sep  6  2020  dolphin_1037a322353321000159884549000000022860011_1599450001_268297
-rw-------. 1 xmas xmas   963 Dec 11  2020  dolphin_1037a322353321000160582296500000086350010_1607711971_615060
-rw-------. 1 xmas xmas  1987 Feb 17  2021  dolphin_1037a322353321000161279960500000691070018_1613583918_421115
-rw-------. 1 xmas xmas  1042 Mar  4  2021  dolphin_1037a322353321000161377122000000040030020_1614903562_226429
-rw-------. 1 xmas xmas   998 Mar  4  2021  dolphin_1037a322353321000161377122000000040030020_1614907965_110246
-rw-------. 1 xmas xmas  1042 Mar  4  2021  dolphin_1037a322353321000161377122000000040030020_1614908657_294212
-rw-------. 1 xmas xmas  1038 Mar  9  2021  dolphin_1037a322353321000161377122000000040030020_1615331973_627914
-rw-------. 1 xmas xmas  1026 Mar  4  2021  dolphin_1037a322353321000161404124800000040030035_1614908657_341409
-rw-------. 1 xmas xmas  1022 Mar  9  2021  dolphin_1037a322353321000161404124800000040030035_1615331973_692953
-rw-------. 1 xmas xmas  1690 Jan  1 11:59  dolphin_1037a322353321000163849756000000072890016_1641059969_722528
-rw-------. 1 xmas xmas  1008 Dec 27 18:24  dolphin_1037a322353321000163855177200000072890018_1640651091_871360
-rw-------. 1 xmas xmas  1008 Jan  1 11:59  dolphin_1037a322353321000163855177200000072890018_1641059969_36583
-rw-------. 1 xmas xmas  1057 Dec 27 18:24  dolphin_1037a322353321000163970863700012098580087_1640651091_12342
-rw-------. 1 xmas xmas  1008 Jan  1 11:59  dolphin_1037a322353321000163970863700012098580087_1641059970_119396
-rw-------. 1 xmas xmas  3281 Jan 29 10:58  dolphin_dolphin_dolphin
-rw-------. 1 xmas xmas   281 Sep  5  2020  kcalc_1097946a8716d9e87615993180802392900000349790100_1599318080_202750
-rw-------. 1 xmas xmas   456 Sep  5  2020  konsole_1037a322353321000159884573300000022860014_1599319311_497916
-rw-------. 1 xmas xmas   456 Sep  7  2020  konsole_1037a322353321000159884573300000022860014_1599515627_778311
-rw-------. 1 xmas xmas   456 Sep 10  2020  konsole_1037a322353321000159884573300000022860014_1599780149_998026
-rw-------. 1 xmas xmas   456 Nov 19  2020  konsole_1037a322353321000159884573300000022860014_1605822963_336847
-rw-------. 1 xmas xmas   530 Dec 11  2020  konsole_1037a322353321000159884573300000022860014_1607711969_384563
-rw-------. 1 xmas xmas   530 Dec 11  2020  konsole_1037a322353321000159884573300000022860014_1607741954_109888
-rw-------. 1 xmas xmas   530 Dec 14  2020  konsole_1037a322353321000159884573300000022860014_1607992663_539481
-rw-------. 1 xmas xmas   530 Dec 14  2020  konsole_1037a322353321000159884573300000022860014_1607997885_467206
-rw-------. 1 xmas xmas   498 Aug 30  2020  kwin_1037a322353321000159875097500000021980004_1598834705_784412
-rw-------. 1 xmas xmas 18473 Jan 22 16:51 'kwin_saved at previous logout_'
-rw-------. 1 xmas xmas   484 Feb 17  2021  okular_1037a322353321000161289742700000691070027_1613583918_160553
-rw-------. 1 xmas xmas   489 Mar  4  2021  okular_1037a322353321000161409672000000040030041_1614886454_134505
-rw-------. 1 xmas xmas   489 Mar  4  2021  okular_1037a322353321000161409672000000040030041_1614903562_216820
-rw-------. 1 xmas xmas   442 Mar  4  2021  okular_1037a322353321000161409672000000040030041_1614907964_960330
-rw-------. 1 xmas xmas   489 Mar  4  2021  okular_1037a322353321000161409672000000040030041_1614908657_195549
-rw-------. 1 xmas xmas   485 Mar  9  2021  okular_1037a322353321000161409672000000040030041_1615331973_634691
-rw-------. 1 xmas xmas   490 Mar  4  2021  okular_1037a322353321000161409767300000040030045_1614903562_243704
-rw-------. 1 xmas xmas   443 Mar  4  2021  okular_1037a322353321000161409767300000040030045_1614907965_76254
-rw-------. 1 xmas xmas   490 Mar  4  2021  okular_1037a322353321000161409767300000040030045_1614908657_303695
-rw-------. 1 xmas xmas   486 Mar  9  2021  okular_1037a322353321000161409767300000040030045_1615331973_662351
-rw-------. 1 xmas xmas   421 Mar  4  2021  okular_1037a322353321000161410962000000040030068_1614907965_184543
-rw-------. 1 xmas xmas   468 Mar  4  2021  okular_1037a322353321000161410962000000040030068_1614908657_367354
-rw-------. 1 xmas xmas   464 Mar  9  2021  okular_1037a322353321000161410962000000040030068_1615331973_957037
-rw-------. 1 xmas xmas   585 Oct 16 15:50  okular_1037a322353321000162915923300002367740017_1634417425_82004
-rw-------. 1 xmas xmas   492 Mar  9  2021  okular_10a94520a79345d90616153433845329300000514720091_1615343384_540350
-rw-------. 1 xmas xmas   503 Mar 11  2021  okular_10a94520a79345d906161549770585936300000514720097_1615497706_602905
-rw-------. 1 xmas xmas   498 Mar 11  2021  okular_10a94520a79345d906161549782220945100000514720098_1615497822_869910
-rw-------. 1 xmas xmas   490 Mar 11  2021  okular_10a94520a79345d9061615497959224400000514720099_1615497959_378715
-rw-------. 1 xmas xmas   467 Mar 11  2021  okular_10a94520a79345d906161550606345371700000514720102_1615506063_754175
-rw-------. 1 xmas xmas   480 Mar 11  2021  okular_10a94520a79345d906161551061997178900000514720103_1615510620_302368
-rw-------. 1 xmas xmas   484 Mar 11  2021  okular_10a94520a79345d906161551089237396100000514720104_1615510892_692075
-rw-------. 1 xmas xmas   427 Mar 17  2021  okular_10d967699e8123e0bc161600755454766100000463810091_1616007554_904981
-rw-------. 1 xmas xmas   455 Mar 17  2021  okular_10d967699e8123e0bc161600779071402800000463810092_1616007790_950934
-rw-------. 1 xmas xmas   455 Mar 17  2021  okular_10d967699e8123e0bc161600787969994100000463810093_1616007879_919177
-rw-------. 1 xmas xmas   436 Mar 17  2021  okular_10d967699e8123e0bc161602244989292700000463810095_1616022450_190657
-rw-------. 1 xmas xmas   432 Mar 17  2021  okular_10d967699e8123e0bc161602247462690200000463810096_1616022474_875628
-rw-------. 1 xmas xmas   447 Mar 17  2021  okular_10d967699e8123e0bc161602250118502800000463810097_1616022501_441813
-rw-------. 1 xmas xmas   455 Mar 17  2021  okular_10d967699e8123e0bc161602261555501800000463810098_1616022615_797613
-rw-------. 1 xmas xmas   453 Mar 19  2021  okular_10d967699e8123e0bc16162015068608800000463810099_1616201506_835204
[xmas@reindeer session]$ cat dolphin_
dolphin_1037a322353321000159884549000000022860011_1599450001_268297
dolphin_1037a322353321000160582296500000086350010_1607711971_615060
dolphin_1037a322353321000161279960500000691070018_1613583918_421115
dolphin_1037a322353321000161377122000000040030020_1614903562_226429
dolphin_1037a322353321000161377122000000040030020_1614907965_110246
dolphin_1037a322353321000161377122000000040030020_1614908657_294212
dolphin_1037a322353321000161377122000000040030020_1615331973_627914
dolphin_1037a322353321000161404124800000040030035_1614908657_341409
dolphin_1037a322353321000161404124800000040030035_1615331973_692953
dolphin_1037a322353321000163849756000000072890016_1641059969_722528
dolphin_1037a322353321000163855177200000072890018_1640651091_871360
dolphin_1037a322353321000163855177200000072890018_1641059969_36583
dolphin_1037a322353321000163970863700012098580087_1640651091_12342
dolphin_1037a322353321000163970863700012098580087_1641059970_119396
dolphin_dolphin_dolphin
[xmas@reindeer session]$ cat dolphin_dolphin_dolphin 
[1]
Active Tab Index=0
Tab Count=1
Tab Data 0=\x00\x00\x00\x02\x00\x00\x00\x000file:///var/local/Projects/VM_370_HELP_2/UPDATED\x00\x00\x00\x00\x01\x00\x00\x00@file:///var/local/Projects/VM_370_HELP_2/UPDATED/DROP.HELPCMD.D1\x00\x00\x00\x01\x00\x00\x00@file:///var/local/Projects/VM_370_HELP_2/UPDATED/DROP.HELPCMD.D1\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x1b\x00\x00\x00\xff\x00\x00\x00\x01\x00\x00\x00\x01\x00\x00\x02\x19\x00\xff\xff\xff\xff\x01\x00\x00\x00\x01\x00
Tab Data 1=\x00\x00\x00\x02\x00\x00\x00\x00\x1bfile:///home/xmas/Documents\x00\x00\x00\x00\x01\x00\x00\x00 file:///home/xmas/Documents/2021\x00\x00\x00\x01\x00\x00\x00 file:///home/xmas/Documents/2021\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x1b\x00\x00\x00\xff\x00\x00\x00\x01\x00\x00\x00\x01\x00\x00\x01\x00\x00\xff\xff\xff\xff\x01\x00\x00\x00\x01\x00
Tab Data 2=\x00\x00\x00\x02\x00\x00\x00\x00Kfile:///home/xmas/Projects/Application_Install_Documentation/ASSIST_Install\x00\x00\x00\x00\x01\x00\x00\x00{file:///home/xmas/Projects/Application_Install_Documentation/ASSIST_Install/.%23How_to_Install_ASSIST_Eventually.txt%23.swp\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x1b\x00\x00\x00\xff\x00\x00\x00\x01\x00\x00\x00\x01\x00\x00\x01\x00\x00\xff\xff\xff\xff\x01\x00\x00\x00\x01\x00
Tab Data 3=\x00\x00\x00\x02\x00\x00\x00\x008file:///home/xmas/Documents/eBooks/IBM/IBM_VM_370/MECAFF\x00\x00\x00\x00\x01\x00\x00\x00Vfile:///home/xmas/Documents/eBooks/IBM/IBM_VM_370/MECAFF/MECAFF-tools-Manual-1.2.5.pdf\x00\x00\x00\x01\x00\x00\x00Vfile:///home/xmas/Documents/eBooks/IBM/IBM_VM_370/MECAFF/MECAFF-tools-Manual-1.2.5.pdf\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x1b\x00\x00\x00\xff\x00\x00\x00\x01\x00\x00\x00\x01\x00\x00\x01\x00\x00\xff\xff\xff\xff\x01\x00\x00\x00\x01\x00
Tab Data 4=\x00\x00\x00\x02\x00\x00\x00\x006file:///home/xmas/Projects/ASSEMBLE_Allow_MACLIB_Input\x00\x00\x00\x00\x01\xff\xff\xff\xff\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x1b\x00\x00\x00\xff\x00\x00\x00\x01\x00\x00\x00\x01\x00\x00\x01\x00\x00\xff\xff\xff\xff\x01\x00\x00\x00\x01\x00

[WindowProperties1]
ClassName=DolphinMainWindow
HDMI-A-0 HDMI-A-1-1 Height 1080=801
HDMI-A-0 HDMI-A-1-1 Height 1920x1080=1051
HDMI-A-0 HDMI-A-1-1 Width 1920=945
HDMI-A-0 HDMI-A-1-1 Width 1920x1080=750
HDMI-A-0 HDMI-A-1-1 XPosition=1924
HDMI-A-0 HDMI-A-1-1 XPosition 1920x1080=2661
HDMI-A-0 HDMI-A-1-1 YPosition=279
HDMI-A-0 HDMI-A-1-1 YPosition 1920x1080=29
HDMI-A-1 HDMI-A-2 Height 1920x1080=1036
HDMI-A-1 HDMI-A-2 Width 1920x1080=789
HDMI-A-1-1 HDMI-A-0 Height 1080=801
HDMI-A-1-1 HDMI-A-0 Width 1920=750
HDMI-A-1-1 HDMI-A-0 XPosition=4
HDMI-A-1-1 HDMI-A-0 YPosition=72
MenuBar=Disabled
ObjectName=Dolphin#1
RestorePositionForNextInstance=false
State=AAAA/wAAAAD9AAAAAwAAAAAAAADUAAAD7fwCAAAAAvsAAAAWAGYAbwBsAGQAZQByAHMARABvAGMAawAAAAAA/////wAAAAoBAAAD+wAAABQAcABsAGEAYwBlAHMARABvAGMAawEAAAAuAAAD7QAAAF0BAAADAAAAAQAAAAAAAAAA/AIAAAAB+wAAABAAaQBuAGYAbwBEAG8AYwBrAAAAAAD/////AAAACgEAAAMAAAADAAAAAAAAAAD8AQAAAAH7AAAAGAB0AGUAcgBtAGkAbgBhAGwARABvAGMAawAAAAAA/////wAAAAoBAAADAAACGQAAA+0AAAAEAAAABAAAAAgAAAAI/AAAAAEAAAACAAAAAQAAABYAbQBhAGkAbgBUAG8AbwBsAEIAYQByAQAAAAD/////AAAAAAAAAAA=
ToolBarsMovable=Disabled
[xmas@reindeer session]$ rm -f *
[xmas@reindeer session]$ ls -l
total 0
[xmas@reindeer session]$ cat /etc/redhat-release 
Fedora release 34 (Thirty Four)
[xmas@reindeer session]$ 

I repositioned all the windows (firefox, Okular, Dolphin, x3270). All the Gnome terminal windows did not reappear.

I found the following in ~/.config/session and removed them.

[xmas@reindeer ~]$ date
Mon Jan 31 07:02:14 PM CST 2022
[xmas@reindeer ~]$ cd .config/session/
[xmas@reindeer session]$ ls -l
total 28
-rw-------. 1 xmas xmas  1161 Jan 31 18:56  dolphin_1037a322353321000164307620400000139320099_1643676980_677606
-rw-------. 1 xmas xmas  1783 Jan 31 18:56  dolphin_1037a322353321000164348439000000139320141_1643676980_677633
-rw-------. 1 xmas xmas  1607 Jan 31 18:56  dolphin_dolphin_dolphin
-rw-------. 1 xmas xmas 12043 Jan 31 18:56 'kwin_saved at previous logout_'
-rw-------. 1 xmas xmas   636 Jan 31 18:56  okular_1037a322353321000164348445600000139320142_1643676980_677779
[xmas@reindeer session]$ rm -f *
[xmas@reindeer session]$ ls -l
total 0
[xmas@reindeer session]$ 


I rebooted my system, and logged in. EVERYTHING is in the first Activity.

What else can I provide to help kill this bug?

 ... Mark S.

The other file involved is .config/ksmserverrc. After deleting the files in .config/session and logging out you should see entries in the journal (journalctl -b) where ksmserver fails to delete the files in .config/session because they don't exist any more.  For your own edification you might try some controlled tests with a small number of virtual desktops and 1 application in a desktop other than 1.

As far as I can tell we have had no response from the developers.

Not sure if it has any effect but perhaps if all who are on this bug list should vote for it. At the moment I am the only one who has.

On Fedora the package "kdebugsettings" seems to be able to get ksmserver (or qt?) to send trace messages to the system journal. The seetings seem to persist over logout/login and/or reboot.  Need to do some controlled tests

When you determine what settings are useful for debugging, please let me know, so, if you need or want it, I can provide additional test data.

What I did was run kdebugsettings command. I turned off  all the things to trace except ksmserver.   Lots more messages appeared in the system journal after a logout/login.  Not sure what they all mean. 

I am not a kde developer by any way. Don't even know much C++. So I will look for messages where something fails. My quick look suggested that ksmserver was starting/stopping more than just the applications I had open on the various virtual desktops (4 in my case). I think we need a kde developer to get involved, but they seem to be quiet on this bug.

You can pick the ksmserver messages in the journal since the last boot with the command "journalctl -b --grep=ksmserver"

I set ksmserver  for "Full Debug" in KDebugSettings dialog.
Rebooted. 
Ran journalctl -b --grep=ksmserver

Nothing ...
[root@reindeer ~]# journalctl -b --grep=ksmserver
-- No entries --
[root@reindeer ~]# 

I'm not  a C++ programmer either. 

I think we are stuck as all the effort is going into Wayland ... and it needs it because tracking windows in Activities is even worse there.

 ... Mark S.

Try running the kdebugsettings from a Konsole window.

(In reply to Brian Kaye from comment #48)
> I think we need a kde developer to get involved, but they seem to be quiet on this bug.

same for me, I have the feeling that since it's a known thing that session restore doesn't work properly with wayland, then no one pay attention to this bug.
but it has nothing to do with wayland, it's plain X11 that used to work for years (well, maybe some commits to fix wayland broke the X11 case, can't really say), if I get some spare time I could try to look at the ksmserver commits before plasma 5.21 was released.
anyway, for me it's major regression since several months / releases, it's sad no one among KDE dev is noticing this ...

(In reply to Nicolas Pomarede from comment #52)
> (In reply to Brian Kaye from comment #48)
> > I think we need a kde developer to get involved, but they seem to be quiet on this bug.
> 
> same for me, I have the feeling that since it's a known thing that session
> restore doesn't work properly with wayland, then no one pay attention to
> this bug.
> but it has nothing to do with wayland, it's plain X11 that used to work for
> years (well, maybe some commits to fix wayland broke the X11 case, can't
> really say), if I get some spare time I could try to look at the ksmserver
> commits before plasma 5.21 was released.
> anyway, for me it's major regression since several months / releases, it's
> sad no one among KDE dev is noticing this ...

Surely at some point in the development process someone on the development team has a test program to verify the contents of .config/session and .config/ksmserverrc. Such a program would help to determine whether its is a session save or session restore problem.

(In reply to Brian Kaye from comment #53)
> (In reply to Nicolas Pomarede from comment #52)
> > (In reply to Brian Kaye from comment #48)
> > > I think we need a kde developer to get involved, but they seem to be quiet on this bug.
> > 
> > same for me, I have the feeling that since it's a known thing that session
> > restore doesn't work properly with wayland, then no one pay attention to
> > this bug.
> > but it has nothing to do with wayland, it's plain X11 that used to work for
> > years (well, maybe some commits to fix wayland broke the X11 case, can't
> > really say), if I get some spare time I could try to look at the ksmserver
> > commits before plasma 5.21 was released.
> > anyway, for me it's major regression since several months / releases, it's
> > sad no one among KDE dev is noticing this ...
> 
> Surely at some point in the development process someone on the development
> team has a test program to verify the contents of .config/session and
> .config/ksmserverrc. Such a program would help to determine whether its is a
> session save or session restore problem.

Surely  it's a session save because I made a copy of the config/session folder before deleting it to see if that would solve the problem and the other day I realized that before December 11, 2021 in the files that starting with dolphin* the information of the position of each window was saved. On day 11 I updated and from there that information is no longer saved:

DP-3 Height 3840x2160=680
DP-3 Width 3840x2160=1252
DP-3 XPosition 3840x2160=329
DP-3 YPosition 3840x2160=1237

I think it's a dolphin problem since the other programs like konsole or kwrite save the positions.

I am a C++ programmer but I have no experience in KDE development, even so I looked at the dolphin commits around that date since it seems that each program is responsible for saving the session information through the kconfig library.

One reason could be that in order for a window to save its position, it uses the kconfig library that has the saveWindowPosition method, in this method there is:

if (!window || QGuiApplication::platformName() == QLatin1String{"wayland"}) {
        return;
    }

This means that in case the application uses wayland, it does not save the position information since session restoration is not implemented in wayland. It may be that due to some change it believes that even if you are using X11 it believes that it uses Wayland since the other data such as the Tabs are saved. (I don't know, I'm just guessing)

Looking at the commits from two months before Dec 11 I had no luck, I don't see any changes that could cause this, I'm stuck.

But if I delete the files in .config/session and the file .config/ksmserverrc, t seems to work correctly at most once  after one logout/login. There appears to be another less serious bug in this. Even though the file .config/ksmserverrc includes what appears to be delete commands  for the files in .config/session for individual applications. These delete commands don't seem to work and after a while there are a lot of old files in .config/session.

My laptop (Lenovo P50) crashed and I fired up an old IBM P42 Thinkpad. It is running Fedora 29 and the bug appears there as well. Don't remember it doing that but it is probbably six  or seven years since I fired that laptop up.  I ran the command  "ksmserver --version" and it returned the exact same version number (0.4) that is running on my Fedora 35 system.

Downloaded Fedora KDE Live 31 the newest version available for old versions. Created and booted a UDB stick. Created 4 virtual desktops, put an application on each desktop, set the system to restore previous. Logout/login 5 times and all desktops had their previous applications on their correct virtual desktop EVERY time. I did not  delete the files in .config/session or the file .ksmserverrc.  Running the command "ksmserver --version" returned the value 0.4.  However here is an anomaly. When I ran "ls  - /usr/ksmserver" It showed a size of 16568 bytes as opposed to the size of 163288 bytes on my fedora 35 system. This difference made me go back and check. Surprising unless the ls command is different the two releases (31 vs 35). I guess I need to find an old version of Fedora 33.

(In reply to Brian Kaye from comment #56)
> My laptop (Lenovo P50) crashed and I fired up an old IBM P42 Thinkpad. It is
> running Fedora 29 and the bug appears there as well. Don't remember it doing
> that but it is probbably six  or seven years since I fired that laptop up. 
> I ran the command  "ksmserver --version" and it returned the exact same
> version number (0.4) that is running on my Fedora 35 system.

I have found an old IBM Thinkpad T60 running Fedora 29. It is a 32Bit installation of Fedora because of the CPU.
Unfortunately, I can not confirm this bug on Fedora 29. Session restore works as expected, but I don't know why.
I guess you are using a 64Bit Fedora?

(In reply to Brian Kaye from comment #56)
> My laptop (Lenovo P50) crashed and I fired up an old IBM P42 Thinkpad. It is
> running Fedora 29 and the bug appears there as well. Don't remember it doing
> that but it is probbably six  or seven years since I fired that laptop up. 
> I ran the command  "ksmserver --version" and it returned the exact same
> version number (0.4) that is running on my Fedora 35 system.

well, this behavior (not remembering desktops and other selected settings properly) only started last summer. and if kmserver is the same version (0.4) since years, it might probably be another component misbehaving.

I downloaded various versions of Fedora KDE Live ISOs and tried them looking for this bug:
Version  | Size of ksmserver | Version | Bug
F31         | 16568                      | 0.4         | No
F33         | 175592                    | 0.4         | Could not logout/in successfully
F34         | 163536                    | 0.4         | Did not restore any applications
F35         | 163288                    | 0.4         | Yes

So running the command "ksmserver --version" is useless for getting the actual version. The size of the programs has changed in different versions so  someone has been doing something to it either directly or indirectly. The Fedora 34 case is interesting in that there was a failure in the kde crash handler. The trace back had several references to Wayland. This may be why the F34 case showed a failure.

I am also curious how this issue will evolve further.

I'm seeing a similar problem. However instead of virtual desktops I heavily rely on Plasma activities. Other than that the behaviour is exactly the same. After rebooting most applications are not properly restored to the Activities I had started them on initially.

This is very annoying as I (use to) have 10+ Konsole windows open spread over 4 activities. Early on I went through the effort of resetting them to the proper activity after reboot, but that became way to cumbersome. I now just have 2 Konsole windows left and I close all other applications before shutting down. So in a way the crippled session restore has caused me to no longer rely on it. But that's an important step backwards in the overal user experience.

I'm currently on Fedora 35, X11. But the problem started somewhere in Fedora 34 for me already.

As others I have tried to remove all files in .config/session. It works for one reboot and afterwards things go wrong again.

The applications I typically left open were Dolphin, Firefox, Kontact and Konsole. I never noticed Firefox restoring properly as I have taken the habit to just shut it down. I'll check this on a future reboot and report back because that could mean only some applications are affected.

I also found this older bug 348047 I had commented on a while back. It deals with the same issue appearing when using plasma activities. I am not completely sure it's the same as with virtual desktops, but the symptoms are very similar. So I thought it worth considering here and cross-referencing them. Perhaps someone with more knowledge can decide whether these are duplicates or not.

I can confirm this with Plasma 5.24 on X11 and would be happy to help by providing log files etc. if someone can tell me which ones are relevant.

Most windows incorrectly end up on the first desktop, though some do correctly remember their desktop; I have not yet found a pattern so far.  

Additionally many windows are restored with an incorrect geometry; maximized windows are often unmaximized and unmaximized windows are often positioned a few pixels off; I can tell because I almost always have all my windows in full/half/quarter tile position and on login they are often displaced by 30px or so, sometimes partially disappearing behind my panel (which I have set to always visible, not windows can go above or below).

And some windows are not restored at all; this seems to be dependent on the application; so far I've noticed that Typora windows are never restored. 

I use automatic restoration of the previous session, not manual save.

Deleting ~/.config/session didn't help.

I just tried it out with restoring from a manually saved session instead of previous session and I'm getting the same behavior.

The problem persists in Fedora 36 with plasma-workspace-5.24.3-3.fc36.x86_64.

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

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

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

Can someone confirm if disabling Plasma's systemd-based startup fixes the issue? To disable it, run
kwriteconfig5 --file startkderc --group General --key systemdBoot false
in a terminal and reboot.
At least for me, session restore seems to work perfectly (remembers which virtual desktops and activities windows were on) on X11 when this is disabled.

this is a good step foreward. after 3 reboots still stable restore confirmed! on
Operating System: Fedora 34
KDE Plasma Version: 5.22.5
KDE Frameworks Version: 5.91.0
Qt Version: 5.15.2
Kernel Version: 5.16.18-100.fc34.x86_64 (64-bit)
Graphics Platform: X11
BUT: dolphin (only app i observed). the dolphin windows are distribute correctly on desktops, but have strange sizes and positions within a desktop/window.

Seems to bypass the problem. After two logout/login and two reboots everything works properly. I am on Fedora 36 but running a fedora 35 kernel (kernel-core-5.17.8-200.fc35.x86_64).  How did you come by this solution?

For me I had two dolphin windows opened on desktop 4 and hey were restored in correct locations and with correct correct sizes.

(In reply to Kishore Gopalakrishnan from comment #70)
> Can someone confirm if disabling Plasma's systemd-based startup fixes the
> issue? 

No, I never had it enabled to begin with.

Is it enabled by default?

(In reply to Brian Kaye from comment #75)
> Is it enabled by default?

Not on my installation. (Arch, Plasma 5.24.5; installed about a year ago after transitioning from Kubuntu while keeping my home folder.)

(In reply to Kishore Gopalakrishnan from comment #70)
> Can someone confirm if disabling Plasma's systemd-based startup fixes the
> issue? To disable it, run
> kwriteconfig5 --file startkderc --group General --key systemdBoot false
> in a terminal and reboot.
> At least for me, session restore seems to work perfectly (remembers which
> virtual desktops and activities windows were on) on X11 when this is
> disabled.

Nothing change with Archlinux Plasma 5.24.5 but for a couple of weeks almost all the windows remember their position but in the case of dolphin after restarting, all the windows have the size of the last one I changed the size of.

Also for dolphin it maintains the same ordering system for all folders even if it has "remember the display style for each folder" activated. On the other hand, in the latest updates when you navigate through the directory tree in the top bar of dolphin, it does not keep the folder it comes from selected. I guess these last two points are new dolphin bugs and are not related to the problem of restoring the session.

As for starting windows on the wrong virtual desktops, at least in my case I have never had this problem.

On my fedora system there is a file dolphin_dolphin_dolphin in .config/session  which seems to be the configuration  of dolphin when it is started after being closed. There are other files dolphin_* which has the configuration of each dolphin window after a session restart

Created attachment 149359 [details]
attachment-3004-0.html

> --- Comment #75 from Brian Kaye <bdk@unb.ca> ---
> Is it enabled by default?

I think it has been enabled by default on Fedora since Fedora 34. On Arch,
it only got enabled for me after upgrading to Plasma 5.24.90. Not sure
about other distros.

I guess the Dolphin issues other people are reporting must be unrelated
(perhaps a different bug).

So it looks like the originally reported bug was indeed related to systemd
startup.

Comment on attachment 149359 [details]
attachment-3004-0.html

Apologies for the attachment. Looks like replying from the Gmail mobile client does that.

(In reply to Kishore Gopalakrishnan from comment #79)

> So it looks like the originally reported bug was indeed related to systemd
> startup.

No, because as said, I have the bug but do not have systemd startup.

(In reply to Natalie Clarius from comment #81)
> (In reply to Kishore Gopalakrishnan from comment #79)
> 
> > So it looks like the originally reported bug was indeed related to systemd
> > startup.
> 
> No, because as said, I have the bug but do not have systemd startup.

Well, the initial bug report says all windows went to the wrong desktop (and that's what I also observed after systemd startup got enabled). You say that "Most windows incorrectly end up on the first desktop, though some do correctly remember their desktop", so it is not clear if your issue is the same bug as the originally reported one.

(In reply to Kishore Gopalakrishnan from comment #82)
> (In reply to Natalie Clarius from comment #81)
> > (In reply to Kishore Gopalakrishnan from comment #79)
> > 
> 
> Well, the initial bug report says all windows went to the wrong desktop (and
> that's what I also observed after systemd startup got enabled). You say that
> "Most windows incorrectly end up on the first desktop, though some do
> correctly remember their desktop", so it is not clear if your issue is the
> same bug as the originally reported one.

Sure, not clear, but certainly relevant. The title still applies, and it would seem likely to me that behavior the OP and I am getting are related, even though the extent varies. If a developer tells me I'm in the wrong place here and I should open a separate bug report for only most windows ending up on the wrong desktop, I can do that.

Firefox always seemed to restore to the correct desktop(s).  But without testing every application its hard to tell if all  other applications exhibit the incorrect behaviour. Firefox may be aware of its desktop configuration when it shuts down. It is certainly aware of which windows it has open.

(In reply to Kishore Gopalakrishnan from comment #70)
> Can someone confirm if disabling Plasma's systemd-based startup fixes the
> issue? To disable it, run
> kwriteconfig5 --file startkderc --group General --key systemdBoot false
> in a terminal and reboot.
> At least for me, session restore seems to work perfectly (remembers which
> virtual desktops and activities windows were on) on X11 when this is
> disabled.
Thanks for this, it fixed my restore issue on my laptop PC. After several reboots, windows are correctly restored on their respective virtual desktop.
But I have mixed results that might match what other reported : I have 2 PC with exact same packages (Mageia 9 dev version), 1 laptop and 1 "normal" pc. On the laptop, session restoring is working again after disabling systemd for kde, but on the other PC session is still not correctly restored (using the same apps (konsole, kwrite, kate) than on the laptop).

So, this really looks like some kind of race condition to me ; starting kde from systemd seems to start components in the wrong order or not waiting enough to ensure each component had enough time to start fully and handle session restoring for example.
On my other PC it still doesn't work as if even when kde starts each component itself (not with systemd) then some parts are not ready to handle session restoring.

In the end, we see that code for restoring session is still working in recent KDE/Plasme, in the sense that session is saved and can be loaded later on next login, but it seems to me that the process that try to restore the session happens too soon / at the wrong time when kde/plasma is not ready yet.

(In reply to Nicolas Pomarede from comment #85)
> (In reply to Kishore Gopalakrishnan from comment #70)
> > Can someone confirm if disabling Plasma's systemd-based startup fixes the
> > issue? To disable it, run
> > kwriteconfig5 --file startkderc --group General --key systemdBoot false
> > in a terminal and reboot.
> > At least for me, session restore seems to work perfectly (remembers which
> > virtual desktops and activities windows were on) on X11 when this is
> > disabled.
> Thanks for this, it fixed my restore issue on my laptop PC. After several
> reboots, windows are correctly restored on their respective virtual desktop.
> But I have mixed results that might match what other reported : I have 2 PC
> with exact same packages (Mageia 9 dev version), 1 laptop and 1 "normal" pc.
> On the laptop, session restoring is working again after disabling systemd
> for kde, but on the other PC session is still not correctly restored (using
> the same apps (konsole, kwrite, kate) than on the laptop).
> 
> So, this really looks like some kind of race condition to me ; starting kde
> from systemd seems to start components in the wrong order or not waiting
> enough to ensure each component had enough time to start fully and handle
> session restoring for example.
> On my other PC it still doesn't work as if even when kde starts each
> component itself (not with systemd) then some parts are not ready to handle
> session restoring.
> 
> In the end, we see that code for restoring session is still working in
> recent KDE/Plasme, in the sense that session is saved and can be loaded
> later on next login, but it seems to me that the process that try to restore
> the session happens too soon / at the wrong time when kde/plasma is not
> ready yet.

I agree. See my comment 29.

(In reply to Brian Kaye from comment #18)
> Problem persists in Fedora 35. System seems to keep older versions of the
> application files in .config/session. What surprises me is that more people
> are not complaining about this problem. That suggests that the problem is
> related to something in my setup. It occurs even if I create a new user.     

Here I am to chime in that this is a problem.

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

With systemd boot becoming the default in 5.25, this is going to start getting a lot more duplicates soon. Bumping priority.

Clearly systemd boot isn't the *only* thing that causes this (as evidenced by the people who still experience the issue with it turned off), but it does seem to be a major driver.

Not sure how relevant it is, but in my logs, I find the following repeated a couple of times (with systemd-startup enabled):
```
Jun 12 15:31:32 kishorearchtestingVM plasmashell[479]: Aborting shell load: The activity manager daemon (kactivitymanagerd) is not running.
Jun 12 15:31:32 kishorearchtestingVM plasmashell[479]: If this Plasma has been installed into a custom prefix, verify that its D-Bus services dir is known to the system for the daemon to be activatable.
```
However, the panels etc. are correctly displayed when the login process is complete. I have installed Plasma from my distro repos. I do not find the above errors in the log when systemd startup is disabled. After some time, I find the log from the successful startup of kactivitymanagerd:
```
Jun 12 15:31:33 kishorearchtestingVM systemd[408]: Started KActivityManager Activity manager Service.
```

-----------------------------------

When I enable debug output for various things, I also find a lot of
```
Jun 12 15:31:33 kishorearchtestingVM plasmashell[479]: kf.activities: Killing the consumer
```
Some of these seem to be emitted a second or so before the restored applications are opened. E.g. from the same boot:
```
Jun 12 15:31:34 kishorearchtestingVM systemd[408]: Started Okular - Document Viewer.
```

SYSTEM INFO
Operating System: Arch Linux
KDE Plasma Version: 5.24.90
KDE Frameworks Version: 5.94.0
Qt Version: 5.15.4
Kernel Version: 5.15.43-1-lts (64-bit)
Graphics Platform: X11
Processors: 4 × AMD EPYC Processor (with IBPB)
Memory: 1.4 GiB of RAM
Graphics Processor: virgl

I can confirm an update to Plasma 5.25 on Tumbleweed with the change to Plasma systemd boot enabled by default triggered this bug.

... and disabling systemd boot fixed it.

The DBus call to kwin to say which session to use fails.

In my logs I see ksmserver make the call before:

Jun 17 15:36:56 david-desktop systemd[922]: plasma-kwin_x11.service: D-Bus name org.kde.KWin now owned by :1.10


In fact we see plasma-restoresession.service super duper early - could explain som kwallet issues.

It's set to be:
"After=graphical-session.target" which I didn't think should count as up until p-w.target is

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

Re. me getting the bug even with systemd boot disabled: It hadn't occured to me earlier that that would make a difference, but I'm normally running source-built KWin on top of stable Plasma (with an XSession file setting the KDEWM variable), and when I just tested logging into the normal session a few times, everything seemed to be restored correctly. So I'm taking back what I said earlier, and it probably really is solely a matter of how things are started up.

I just upgraded to openSUSE Tumbleweed 20220616 with KDE Plasma 5.25 and on login immediately experienced this bug.

I can confirm the expected/correct login session behaviour was restored after disabling systemdBoot by having the session user perform:

kwriteconfig5 --file startkderc --group General --key systemdBoot false

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

A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1859

Git commit a22ff36edf108fc710e2056e7fa5cc21447e53a3 by David Edmundson.
Committed on 22/06/2022 at 11:30.
Pushed by davidedmundson into branch 'master'.

Fix session restore + kwin interaction race

KSMServer sets which session to use on startup
`KSmServer::restoreSession(QString)`

When the session is up and ready either systemd or plasma-session invoke
`restoreSession()` that actively starts restoring clients.

At some point we need to notify kwin which session we're using so that
it can handle restorng window properties such as the virtual desktop.

This was done in the first call, but this has no guarantee that kwin has
started yet. Without kwin getting the DBus call it has no information to
match up restoration information.

The state RestoringWMSession is dropped as it does nothing useful.

M  +11   -13   ksmserver/server.cpp
M  +0    -1    ksmserver/server.h

https://invent.kde.org/plasma/plasma-workspace/commit/a22ff36edf108fc710e2056e7fa5cc21447e53a3

Git commit 93416bb280493d8173ab289903c12ab77c67c4ae by David Edmundson.
Committed on 22/06/2022 at 12:42.
Pushed by davidedmundson into branch 'Plasma/5.25'.

Fix session restore + kwin interaction race

KSMServer sets which session to use on startup
`KSmServer::restoreSession(QString)`

When the session is up and ready either systemd or plasma-session invoke
`restoreSession()` that actively starts restoring clients.

At some point we need to notify kwin which session we're using so that
it can handle restorng window properties such as the virtual desktop.

This was done in the first call, but this has no guarantee that kwin has
started yet. Without kwin getting the DBus call it has no information to
match up restoration information.

The state RestoringWMSession is dropped as it does nothing useful.


(cherry picked from commit a22ff36edf108fc710e2056e7fa5cc21447e53a3)

M  +11   -13   ksmserver/server.cpp
M  +0    -1    ksmserver/server.h

https://invent.kde.org/plasma/plasma-workspace/commit/93416bb280493d8173ab289903c12ab77c67c4ae

Need to get the various distros to pick this up and then turn systemd boot back on. Is the retention of files in .config/session fixed as well or is it a separate bug. Still would like to know the what the contents of the .config/session  and .config/ksmserverrc  files mean.

>Need to get the various distros to pick this up and then turn systemd boot back on. 

Who's turned it off? 

>Is the retention of files in .config/session fixed as well or is it a separate bug

Unrelated to this.

(In reply to David Edmundson from comment #102)
> >Need to get the various distros to pick this up and then turn systemd boot back on. 
> 
> Who's turned it off? 
> 
> >Is the retention of files in .config/session fixed as well or is it a separate bug
> 
> Unrelated to this.

I have turned it off as a result of a comment on this bug report..

I wonder if the race condition has created the situation where the files are not deleted in .config/session. Once the distros pick up the change  we will see if the deletion is still necessary.

I ran the command "kwriteconfig5 --file startkderc --group General --key systemdBoot false" which seemed to correct the problem. The file .config/startkderc was changed(or created)   . The file "/etc/xdg/startkderc"  still shows  "systemdBoot=true". Once the distros pick this change up (fedora has not as of this post) we will have to delete .config/startkderc or run the command "kwriteconfig5 --file startkderc --group General --key systemdBoot true" . This should be done before the fixed package is installed  to verify that the new package fixes the problem. Sure wish fedora would hurry up so we can put this issue to bed.

Ran kwriteconfig5 --file startkderc --group General --key systemdBoot true and installed "plasma-workspace-common-5.25.2-1.fc36.x86_64" and associated packages on my Fedora 36 system.  Had to try a number of times before it worked though. Seems to work correctly now. But still does not remove the old files in .config/session. Probably a different bug.

Hopefully my last comment. Deleted all files in .config/session and started apps one at a time. All old files controlled by ksmserverrc were deleted at each logout/login. So no bug.

Observed with openSUSE 15.3 Plasma 5.25.0 RPMs.  This did not occur with Plasma 5.24; windows were restored correctly.  I am running X11.

> Observed with openSUSE 15.3 Plasma 5.25.0 RPMs
As the "Version Fixed In" field says, it's fixed in 5.25.2. You don't have that yet.

With the newest version, systemd startup enabled and accordingly the custom WM startup method switched to a systemd user unit, the problem is now resolved for my setup (source-built KWin on top of stable Plasma) as well.

OpenSUSE tumbleweed is now on 5.25.2.  I removed ~/.config/startkderc which did contain [General] systemdBoot=false.  I checked the value of kreadconfig5   --group General --key systemdBoot - it reports nothing - I presume that means the system is using the default.  After logging out and logging in again, all desktops were correctly restored and ~/.config/startkderc was still absent.  So the fix appears to be working for me.

Is there a journal message that confirms systemd boot is now responsible for performing the restore?

(In reply to Michael Hamilton from comment #110)
> Is there a journal message that confirms systemd boot is now responsible for
> performing the restore?
After logging in, run
```
systemctl --user status plasma-restoresession.service
```
in a terminal.

You should see something like
```
○ plasma-restoresession.service - KDE Session Management Server
     Loaded: loaded (/usr/lib/systemd/user/plasma-restoresession.service; static)
     Active: inactive (dead) since Sat 2022-07-16 18:58:16 IST; 4s ago
    Process: 544 ExecStart=/usr/bin/qdbus org.kde.ksmserver /KSMServer org.kde.KSMServerInterface.restoreSession (code=exited, status=0/SUCCESS)
   Main PID: 544 (code=exited, status=0/SUCCESS)
        CPU: 11ms

Jul 16 18:58:14 kishorearchtestingVM systemd[392]: Starting KDE Session Management Server...
Jul 16 18:58:16 kishorearchtestingVM systemd[392]: Finished KDE Session Management Server.
```
if systemd is being used for KDE's session restoration.

(In reply to Kishore Gopalakrishnan from comment #111)
> (In reply to Michael Hamilton from comment #110)
> > Is there a journal message that confirms systemd boot is now responsible for
> > performing the restore?
> After logging in, run
> ```
> systemctl --user status plasma-restoresession.service
> ```
> in a terminal.
> ...

Thanks. That worked and confirmed that the service had run successfully.