The bug is presumably caused by recent changes in plasma-workspace made in 6.0.5.1, namely, in ksmserver (server.cpp and server.h).

plasma-workspace 6.0.5 is free of this bug

I also have this bug. Interestingly, applications are still opened correctly (preserving their previous state) when resuming an activity.

(In reply to Kishore Gopalakrishnan from comment #2)
> ... Interestingly, applications are still opened correctly
> (preserving their previous state) when resuming an activity.

Scratch that. Activity supension/resumption also doesn't work for me.

When I suspend an activity, I can see using htop that those applications are still running (and thus, they still appear if I resume the same activity without rebooting). However, attempting to resume the activity after rebooting, one is indeed presented with just an empty activity.

Installing the xorg-iceauth package does not help for me.

After enabling 'full debug' output for ksmserver and rebooting, I get the following messages in `journalctl -b -0 --user` (I have only reproduced a segment that seems relevant)
```
Jun 02 14:59:53 kishorearchtestingVM systemd[499]: Started KDE Daemon 6.
Jun 02 14:59:53 kishorearchtestingVM ksmserver[588]: org.kde.kf6.ksmserver: "/run/user/1000/KSMserver"
Jun 02 14:59:53 kishorearchtestingVM systemd[499]: Starting KDE Configuration Module Initialization (Phase 1)...
Jun 02 14:59:53 kishorearchtestingVM ksmserver[588]: Failed to write ice auth file entry
Jun 02 14:59:53 kishorearchtestingVM ksmserver[588]: Failed to write xsmp ice auth file entry
Jun 02 14:59:53 kishorearchtestingVM ksmserver[588]: Failed to write ice auth file entry
Jun 02 14:59:53 kishorearchtestingVM ksmserver[588]: Failed to write xsmp ice auth file entry
Jun 02 14:59:53 kishorearchtestingVM ksmserver[588]: org.kde.kf6.ksmserver: KSMServer::restoreSession  "saved at previous logout"
Jun 02 14:59:53 kishorearchtestingVM systemd[499]: Started KDE Session Management Server.
Jun 02 14:59:53 kishorearchtestingVM systemd[499]: Starting KDE Plasma Workspace...
Jun 02 14:59:53 kishorearchtestingVM kcminit_startup[550]: Initializing  "/usr/lib/qt6/plugins/plasma/kcms/systemsettings/kcm_touchpad.so"
Jun 02 14:59:53 kishorearchtestingVM kcminit_startup[550]: kcm_touchpad: Using X11 backend
Jun 02 14:59:53 kishorearchtestingVM kcminit_startup[550]: Initializing  "/usr/lib/qt6/plugins/plasma/kcms/systemsettings_qwidgets/kcm_kgamma.so"
Jun 02 14:59:53 kishorearchtestingVM systemd[499]: Finished KDE Configuration Module Initialization (Phase 1).
Jun 02 14:59:53 kishorearchtestingVM kded6[590]: org.kde.libkbolt: Failed to connect to Bolt manager DBus interface:
Jun 02 14:59:53 kishorearchtestingVM kded6[590]: org.kde.bolt.kded: Couldn't connect to Bolt DBus daemon
Jun 02 14:59:53 kishorearchtestingVM systemd[499]: Started KDE Window Manager.
Jun 02 14:59:53 kishorearchtestingVM kded6[590]: org.kde.plasma.printmanager.kded: unable to register service to dbus
Jun 02 14:59:53 kishorearchtestingVM kded6[590]: QDBusObjectPath: invalid path "/modules/plasma-session-shortcuts"
Jun 02 14:59:53 kishorearchtestingVM kded6[590]: kf.dbusaddons: The kded module name "plasma-session-shortcuts" is invalid!
Jun 02 14:59:53 kishorearchtestingVM systemd[499]: Starting KActivityManager Activity manager Service...
Jun 02 14:59:53 kishorearchtestingVM kded6[590]: QDBusObjectPath: invalid path "/modules/kded_plasma-welcome"
Jun 02 14:59:53 kishorearchtestingVM kded6[590]: kf.dbusaddons: The kded module name "kded_plasma-welcome" is invalid!
Jun 02 14:59:53 kishorearchtestingVM kded6[590]: kcm_touchpad: Using X11 backend
Jun 02 14:59:53 kishorearchtestingVM ksmserver[588]: org.kde.kf6.ksmserver: KSMConnection::count 1
Jun 02 14:59:53 kishorearchtestingVM ksmserver[588]: org.kde.kf6.ksmserver: ICE Connection rejected!
Jun 02 14:59:53 kishorearchtestingVM plasmashell[607]: Qt: Session management error: None of the authentication protocols specified are supported
```

In ksmserver/server.cpp, I see (around line 365)
```
            if (IceWriteAuthFileEntry(fp, file_entry) != 0) {
                qWarning("Failed to write ice auth file entry");
            }
```
but the documentation for IceWriteAuthFileEntry ( https://www.x.org/releases/X11R7.7/doc/libICE/ICElib.html#IceWriteAuthFileEntry ) says "The function returns a nonzero status if the operation was successful. "

I suppose this means the 'Failed to write ice auth file entry' messages in my logs in comment 5 may be misleading.

I can at least confirm that my iceauth file (/run/user/1000/iceauth_XXXXXX , where XXXXXX is some apparently random string) is empty, so perhaps ksmserver is indeed failing to write the 'magic cookie' (whatever that is) to that file.

Confirmed, this happens with the latest version of plasma-workspace 6.0.5.1, if I install the previous 6.0.5 the session restoration works again

I can confirm this, luckily I could revert to 6.0.5, heavily rely on session restore functionality.
I even restored home FS to a snapshot before I logged in with broken session restore, to be sure.

(In reply to Kishore Gopalakrishnan from comment #7)
> I can at least confirm that my iceauth file (/run/user/1000/iceauth_XXXXXX ,
> where XXXXXX is some apparently random string) is empty, so perhaps
> ksmserver is indeed failing to write the 'magic cookie' (whatever that is)
> to that file.

I don't even have this file on my system with 6.0.5 where everything works just fine. So I would not be so sure that the issue is there.

(In reply to Eduardo from comment #10)
> (In reply to Kishore Gopalakrishnan from comment #7)
> > I can at least confirm that my iceauth file (/run/user/1000/iceauth_XXXXXX ,
> > where XXXXXX is some apparently random string) is empty, so perhaps
> > ksmserver is indeed failing to write the 'magic cookie' (whatever that is)
> > to that file.
> 
> I don't even have this file on my system with 6.0.5 where everything works
> just fine. So I would not be so sure that the issue is there.

That is the issue. With new release this file is created, written, but not flushed or closed, so it stays empty. And new env variable ICEAUTHORITY pointing to this file is set up. Flushing or closing file fixed issue for me with plasma workspace 5.27.11.1 as in https://bugs.kde.org/show_bug.cgi?id=487936#c3.

(In reply to i.Dark_Templar from comment #11)
> 
> That is the issue. With new release this file is created, written, but not
> flushed or closed, so it stays empty. And new env variable ICEAUTHORITY
> pointing to this file is set up. Flushing or closing file fixed issue for me
> with plasma workspace 5.27.11.1 as in
> https://bugs.kde.org/show_bug.cgi?id=487936#c3.

Could you explain how can one close or flush this file?

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

(In reply to i.Dark_Templar from comment #11)
> That is the issue. With new release this file is created, written, but not
> flushed or closed, so it stays empty. And new env variable ICEAUTHORITY
> pointing to this file is set up. Flushing or closing file fixed issue for me
> with plasma workspace 5.27.11.1 as in
> https://bugs.kde.org/show_bug.cgi?id=487936#c3.

Good catch!

After plasma workspace 6.0.5.1 is rebuilt with the following patch applied, everything seems to be quite right: 
-- $ICEAUTHORITY=/run/user/1000/iceauth_XXXXX
-- file iceauth_XXXXX does exist and is not empty
-- plasma X11 session is saved and restored correctly.

--- a/ksmserver/server.cpp<---->2024-05-31 15:48:02.000000000 +0300
+++ b/ksmserver/server.cpp<---->2024-06-04 08:47:52.966458262 +0300
@@ -397,6 +397,7 @@
         IceSetPaAuthData(2, &(*authDataEntries)[i]);
     }
.
+    (void)fclose(fp);
     return (1);
 }

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

Thanks for following up so quickly.

In addition to Comment 15:
There are still the following messages in journalctl:

ksmserver[983]: Failed to write ice auth file entry
ksmserver[983]: Failed to write xsmp ice auth file entry
ksmserver[983]: Failed to write ice auth file entry
ksmserver[983]: Failed to write xsmp ice auth file entry

However, iceauth command shows that all the entries are is written correctly into the /run/user/1000/iceauth_XXXXX file.

Kishore Gopalakrishnan in Comment #6 notices that the function IceWriteAuthFileEntry returns a nonzero status if the operation was successful. 
So the condition "if (IceWriteAuthFileEntry(fp, file_entry) != 0)" in ksmserver/server.cpp (lines 367,391) should be "if (IceWriteAuthFileEntry(fp, file_entry) = 0)"

Git commit 0dcf34458d99b07a3d9054ae0c86c656e0dfa7aa by Fushan Wen, on behalf of Tomáš Trnka.
Committed on 04/06/2024 at 11:39.
Pushed by fusionfuture into branch 'master'.

Fix writing ICEAuthority file

Commit 9398f6cf8933055b31506ba155aef2fc2b3561d7 "Remove iceauth
dependency" introduced two bugs:

1) "fp" is never closed, so the generated auth data stays buffered in
   memory for some indeterminate time and the file stays empty on disk.
   This completely breaks authentication and thus also session restore.

2) Checking the return value of IceWriteAuthFileEntry() is inverted (the
   function returns non-zero on success), so warnings are printed iff
   everything goes well.

M  +7    -2    ksmserver/server.cpp

https://invent.kde.org/plasma/plasma-workspace/-/commit/0dcf34458d99b07a3d9054ae0c86c656e0dfa7aa

Git commit 0857d18dfc3fc870a7f768731fdf46dc3abc5f8f by Fushan Wen.
Committed on 04/06/2024 at 12:17.
Pushed by fusionfuture into branch 'Plasma/6.1'.

Fix writing ICEAuthority file

Commit 9398f6cf8933055b31506ba155aef2fc2b3561d7 "Remove iceauth
dependency" introduced two bugs:

1) "fp" is never closed, so the generated auth data stays buffered in
   memory for some indeterminate time and the file stays empty on disk.
   This completely breaks authentication and thus also session restore.

2) Checking the return value of IceWriteAuthFileEntry() is inverted (the
   function returns non-zero on success), so warnings are printed iff
   everything goes well.


(cherry picked from commit 0dcf34458d99b07a3d9054ae0c86c656e0dfa7aa)

Co-authored-by: Tomáš Trnka <tomastrnka@gmx.com>

M  +7    -2    ksmserver/server.cpp

https://invent.kde.org/plasma/plasma-workspace/-/commit/0857d18dfc3fc870a7f768731fdf46dc3abc5f8f

Git commit 1181acfe30557d6646511df8d98d82589878a570 by Fushan Wen.
Committed on 04/06/2024 at 12:18.
Pushed by fusionfuture into branch 'Plasma/5.27'.

Fix writing ICEAuthority file

Commit 9398f6cf8933055b31506ba155aef2fc2b3561d7 "Remove iceauth
dependency" introduced two bugs:

1) "fp" is never closed, so the generated auth data stays buffered in
   memory for some indeterminate time and the file stays empty on disk.
   This completely breaks authentication and thus also session restore.

2) Checking the return value of IceWriteAuthFileEntry() is inverted (the
   function returns non-zero on success), so warnings are printed iff
   everything goes well.


(cherry picked from commit 0dcf34458d99b07a3d9054ae0c86c656e0dfa7aa)

Co-authored-by: Tomáš Trnka <tomastrnka@gmx.com>

M  +7    -2    ksmserver/server.cpp

https://invent.kde.org/plasma/plasma-workspace/-/commit/1181acfe30557d6646511df8d98d82589878a570

I have also noticed that gtk apps that are on the desktop (I use gkrellm) multiply after logout/login or reboot. I have gkrellm on the desktop and I noticed many copies of it running. I killed them all started one and tested again and they keep multiplying. I will test to see if this patch fixes that too.

No it did not. I will open a new case

This needs to be backported to 6.0 too (and a 6.0.5.2 tarball released). Currently there is a security advisory asking users to upgrade to a broken version.

Fedora 40 included these patches in a new version. However, it seems to break the logout from KDE plasma. When I select logout (on multiple computers) I get a black screen with the mouse cursor showing only.

Git commit 918cb38c3522ffcc241ac6a22b6741e41cdd3c30 by David Edmundson, on behalf of David Edmundson.
Committed on 09/06/2024 at 08:25.
Pushed by davidedmundson into branch 'Plasma/6.0'.

Fix writing ICEAuthority file

Commit 9398f6cf8933055b31506ba155aef2fc2b3561d7 "Remove iceauth
dependency" introduced two bugs:

1) "fp" is never closed, so the generated auth data stays buffered in
   memory for some indeterminate time and the file stays empty on disk.
   This completely breaks authentication and thus also session restore.

2) Checking the return value of IceWriteAuthFileEntry() is inverted (the
   function returns non-zero on success), so warnings are printed iff
   everything goes well.


(cherry picked from commit 0dcf34458d99b07a3d9054ae0c86c656e0dfa7aa)

Co-authored-by: Tomáš Trnka <tomastrnka@gmx.com>

M  +7    -2    ksmserver/server.cpp

https://invent.kde.org/plasma/plasma-workspace/-/commit/918cb38c3522ffcc241ac6a22b6741e41cdd3c30

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

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

It still happens again and again and again!!! Plasma 6.1.4. Please fix!

(In reply to Aleksey Kontsevich from comment #32)
> (In reply to Nate Graham from comment #30)
> > This is an X11-specific bug; you're talking about the general issue that
> > real session restore isn't implemented on Wayland yet. That's different; see
> 
> 
> No, not different!!! I'm on X11 - not Wayland!

I can confirm! This keeps happening to me on openSuSE Leap, but also on Tumbleweed which has the newest updates sporadically since about 2 months. The last time a couple of days ago.
And I don't have Wayland as well !

(In reply to zb4ng from comment #33)
> (In reply to Aleksey Kontsevich from comment #32)
> > (In reply to Nate Graham from comment #30)
> > > This is an X11-specific bug; you're talking about the general issue that
> > > real session restore isn't implemented on Wayland yet. That's different; see
> > 
> > 
> > No, not different!!! I'm on X11 - not Wayland!
> 
> I can confirm! This keeps happening to me on openSuSE Leap, but also on
> Tumbleweed which has the newest updates sporadically since about 2 months.
> The last time a couple of days ago.
> And I don't have Wayland as well !

True! Happens for me on openSuSE Tumbleweed.

Happened today again!

Shit, happened today again twice with 2 subsequent reboots - completely lost! Please fix! This is boring!!!

Happened today again! Rebooted X11 by Ctrl-Alt-Backspace - session restored again. Is it possible some config left after Wayland and if to delete it then session restoration will work again?

(In reply to Aleksey Kontsevich from comment #37)
> Happened today again! Rebooted X11 by Ctrl-Alt-Backspace - session restored
> again. Is it possible some config left after Wayland and if to delete it
> then session restoration will work again?

The bug in this report is fixed (the symptoms are described in comment 5 ).

To check if it is some config issue, try creating a fresh user account (see if session restore works, say, 30 times in a row in that account).

Your bug may be one of the following bugs. If not, file a new report with more information.
https://bugs.kde.org/show_bug.cgi?id=491130
https://bugs.kde.org/show_bug.cgi?id=491421

(In reply to S. Umar from comment #25)
> Fedora 40 included these patches in a new version. However, it seems to
> break the logout from KDE plasma. When I select logout (on multiple
> computers) I get a black screen with the mouse cursor showing only.
Same behaviour confirmed by a Gentoo user of Plasma 6.1.4 with X11 session.

Fixed after reverting 0dcf34458d99b07a3d9054ae0c86c656e0dfa7aa

So this continues to be problematic.

(In reply to S. Umar from comment #25)
> Fedora 40 included these patches in a new version. However, it seems to
> break the logout from KDE plasma. When I select logout (on multiple
> computers) I get a black screen with the mouse cursor showing only.

To anyone else with this problem, please try to reproduce the problem with a newly created testuser profile.

(In reply to Andreas Sturmlechner from comment #40)
> To anyone else with this problem, please try to reproduce the problem with a
> newly created testuser profile.

This is related to openSUSE LEAP.
Around 10 days ago , I switched to a complete new user account that I have used since then. It worked just fine until now, when it all happened again (a couple of dolphin windows showing home folder instead of the folders before the last shutdown, no okular windows etc).

(In reply to zb4ng from comment #41)

> This is related to openSUSE LEAP.
> Around 10 days ago , I switched to a complete new user account that I have
> used since then. It worked just fine until now, when it all happened again
> (a couple of dolphin windows showing home folder instead of the folders
> before the last shutdown, no okular windows etc).

Periodically in openSUSE Tubleweed I have EXACTLY the same: a couple of dolphin windows showing home folder instead of the folders before the last shutdown, no okular windows etc.

@ those affected by "partial" restores (programs only restored in their default state): If it happens again: could check whether there's a file in  ~/.config/session/  whose id matches that of the "restartCommand*" line in  ~/.config/ksmserverrc ?  Like
session-file: dolphin_104c55580000172605190600000090300033_1726072968_326808
ksmserverrc:  restartCommand11=/opt/kf5/bin/dolphin,-session,104c55580000172605190600000090300033_1726072968_326808

I suspect that in case of partial restores the program specific session-files are missing.   The outcome of a little experiment seems to corroborate this: I logged out of Plasma, found a new pair of matching ids for Dolphin and intentionally deleted the newly created session-file for Dolphin which had many open tabs at logout.  After login in Plasma Dolphin was restored but only with one window, showing the home directory.  The other KDE-programs were restored fine.

In case of complete session-restore failure  ~/.config/ksmserverrc  may be incomplete (no "restartCommand*" lines), see: https://bugs.kde.org/show_bug.cgi?id=488520.

Some things I tried to avoid this mess and/or find out why this happens:
Every login, I create a log: 
journalctl /usr/bin/plasmashell

Whenever the bug happens, then this is in the log:
plasmashell[2581]: Qt: Session management error: Authentication Rejected, reason : MIT-MAGIC-COOKIE-1 authentication rejected
plasmashell[2581]: Aborting shell load: The activity manager daemon (kactivitymanagerd) is not running.
plasmashell[2581]: 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.
see also here: https://bugs.kde.org/show_bug.cgi?id=491130#c1

Now the "magic cookie" is managed by the X-Server for authentication purposes (I don't really know what's going on there and I couldn't find very detailed info about this).
What I presume now is that there are at least two possible things that could be the cause:
Either: Sometimes, "activity manager daemon" doesn't start in time for the Xauthority/magic cookie stuff.
Or: The activity manager daemon doesn't start because the authentication got rejected.

In the light of this, I tried the following workarounds, but wo success:
1. add xhost +local: to ~/.profile in the hope that the X-Server authentication gets skipped.
2. boot and then wait two minutes before logging into the X-Server

(In reply to zb4ng from comment #44)
> Whenever the bug happens, then this is in the log:
> plasmashell[2581]: Qt: Session management error: Authentication Rejected,
> reason : MIT-MAGIC-COOKIE-1 authentication rejected
> plasmashell[2581]: Aborting shell load: The activity manager daemon
> (kactivitymanagerd) is not running.
> plasmashell[2581]: 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.
> see also here: https://bugs.kde.org/show_bug.cgi?id=491130#c1
> 
> Now the "magic cookie" is managed by the X-Server for authentication
> purposes (I don't really know what's going on there and I couldn't find very
> detailed info about this).
> What I presume now is that there are at least two possible things that could
> be the cause:
> Either: Sometimes, "activity manager daemon" doesn't start in time for the
> Xauthority/magic cookie stuff.
> Or: The activity manager daemon doesn't start because the authentication got
> rejected.

Maybe plasma-plasmashell.service just needs to depend on plasma-kactivitymanagerd.service? I just tried to add the following via `systemctl --user edit plasma-plasmashell.service`:
[Unit]
After=plasma-kactivitymanagerd.service

Will see if it helps during the next reboot(s).

(In reply to zb4ng from comment #44)
> Some things I tried to avoid this mess and/or find out why this happens:
> Every login, I create a log: 
> journalctl /usr/bin/plasmashell
> 
> Whenever the bug happens, then this is in the log:
> plasmashell[2581]: Qt: Session management error: Authentication Rejected,
> reason : MIT-MAGIC-COOKIE-1 authentication rejected
> plasmashell[2581]: Aborting shell load: The activity manager daemon
> (kactivitymanagerd) is not running.
> plasmashell[2581]: 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.
> see also here: https://bugs.kde.org/show_bug.cgi?id=491130#c1
> 
> Now the "magic cookie" is managed by the X-Server for authentication
> purposes (I don't really know what's going on there and I couldn't find very
> detailed info about this).
> What I presume now is that there are at least two possible things that could
> be the cause:
> Either: Sometimes, "activity manager daemon" doesn't start in time for the
> Xauthority/magic cookie stuff.
> Or: The activity manager daemon doesn't start because the authentication got
> rejected.
> 
> In the light of this, I tried the following workarounds, but wo success:
> 1. add xhost +local: to ~/.profile in the hope that the X-Server
> authentication gets skipped.
> 2. boot and then wait two minutes before logging into the X-Server

I haven't seen this for a while but if you encounter it often you could try to avoid losing your session by switching to "Restore from manually saved session" in systemsettings and then use the session-menu to manually save your session or execute 

	dbus org.kde.ksmserver /KSMServer org.kde.KSMServerInterface.saveCurrentSession

in a terminal while in a Plasma-session (for automation one could use fcron).  This works for Plasma-5, not sure about Plasma-6.

This is based on the assumption/observation that the bug leads to a corrupted/incomplete ~/.config/ksmserverrc and/or missing session-files in ~/.config/session when using the usual way of saving the session at logout and that this does not happen when saving the session manually.

Unfortuately, the dbus-method doesn't seem to work at logout and thus cannot be automated with a logout-script (I've tried; also see [1]).

HTH.

---
[1] https://superuser.com/questions/699857/save-session-using-shell-command-in-kde

/ snip /
> 
> 	dbus org.kde.ksmserver /KSMServer
> org.kde.KSMServerInterface.saveCurrentSession
> 
Sorry, that should have been

 qdbus org.kde.ksmserver /KSMServer org.kde.KSMServerInterface.saveCurrentSession

Copied somewhat slovenly from the command line.

Plasma 6.2 works much better: all apps are restored - even Chromium based browser, which NEVER happened before.

(In reply to Aleksey Kontsevich from comment #48)
> Plasma 6.2 works much better: all apps are restored - even Chromium based
> browser, which NEVER happened before.

The issue is not that Plasma-X11-sessions are never restored but that they are randomly not restored.

Seems works fine now again.

(In reply to Aleksey Kontsevich from comment #42)
> (In reply to zb4ng from comment #41)
> 
> > This is related to openSUSE LEAP.
> > Around 10 days ago , I switched to a complete new user account that I have
> > used since then. It worked just fine until now, when it all happened again
> > (a couple of dolphin windows showing home folder instead of the folders
> > before the last shutdown, no okular windows etc).
> 
> Periodically in openSUSE Tubleweed I have EXACTLY the same: a couple of
> dolphin windows showing home folder instead of the folders before the last
> shutdown, no okular windows etc.

This happens today again. So not fixed, sorry. Workaround: restart (kill) X11 by Ctrl-Alt-Bckspc, start session again.

(In reply to Ondrej Mosnáček from comment #45)
> I haven't seen this for a while but if you encounter it often you could try
> to avoid losing your session by switching to "Restore from manually saved
> session" in systemsettings and then use the session-menu to manually save
> your session 
Tried this, but, unfortunately, doesn't help.
> or execute 
> 
> 	dbus org.kde.ksmserver /KSMServer
> org.kde.KSMServerInterface.saveCurrentSession
> 
> in a terminal while in a Plasma-session (for automation one could use
> fcron).  This works for Plasma-5, not sure about Plasma-6.
> 
I didn't try this one yet but I assume this does the same thing ?

Anyway, I thought about switching to Wayland, but then found out that people are complaining  about a lot of issues.

(In reply to zb4ng from comment #52)
> (In reply to Ondrej Mosnáček from comment #45)
> > I haven't seen this for a while but if you encounter it often you could try
> > to avoid losing your session by switching to "Restore from manually saved
> > session" in systemsettings and then use the session-menu to manually save
> > your session 
> Tried this, but, unfortunately, doesn't help.
Sorry to hear that.  I've tested it with Plasma-5.27.11 where it works.  According to what you and others report here the situation seems to be worse for Plasma-6 than for Plasma-5.  I'm still with Plasma-5.27.11 and as I've said, it's not been a problem for me for quite a while now.  But a fellow BLFS-user, also using Plasma-5.27.11, already warned me that he had not encountered the bug for two months before it struck again several times.

> > or execute 
> > 
> > 	dbus org.kde.ksmserver /KSMServer
> > org.kde.KSMServerInterface.saveCurrentSession
> > 
> > in a terminal while in a Plasma-session (for automation one could use
> > fcron).  This works for Plasma-5, not sure about Plasma-6.
> > 
> I didn't try this one yet but I assume this does the same thing ?
Essentially, yes.  But with the method via "Systemsettings" you have to log out and in again before the option for manually saving the session is displayed in the the start-menu.  With  "qdbus org.kde.ksmserver /KSMServer org.kde.KSMServerInterface.saveCurrentSession"  you can do it right away.
> 
> Anyway, I thought about switching to Wayland, but then found out that people
> are complaining  about a lot of issues.
AFAIK, there's still no proper session-restore for Plasma-Wayland.  And it seems that it can't be implemented as long as an equivalent of the  X Session Management Protocol (XSMP; since 1992 or so) is missing in Wayland.

(In reply to David Edmundson from comment #54)
> >Seems works fine now again.
> 
> Closing this.

Do not close this! Not fixed! Read my next comment: comment #51

> Wayland is a separate topic that isn't helpful to discuss here.

It is not on Wayland. It is on X11!

>You should at least explain what the problem was and how it was fixed

The original bug report is about ICE, which is a duplicate of 487912 and fixed by plasma-workspace 0dcf34458d99b07a3d9054ae0c86c656e0dfa7aa


We've jumped across a few topics. Can someone with an issue please make a new ticket containing output of:

`cat ~/.config/ksmserverrc` after it fails to restore. 
`journalctl --user -b -u plasma-ksmserver`

Yep. A new bug report would be helpful here, since clearly there are multiple issues. Each one needs its own bug report so we don't all get confused about which one is tracking what. Thanks everyone!

(In reply to David Edmundson from comment #58)
> We've jumped across a few topics. Can someone with an issue please make a
> new ticket containing output of:
> 
> `cat ~/.config/ksmserverrc` after it fails to restore. 
> `journalctl --user -b -u plasma-ksmserver`

I'll do when happens next time, however suspect something still wrong with session restore:
- with Akregator - happens after session restore: Bug 494071
- with Chromium: if it has multiple windows, after session restore it opens more windows than it had on logout.

(In reply to Nate Graham from comment #60)
> Yep. A new bug report would be helpful here, since clearly there are
> multiple issues. Each one needs its own bug report so we don't all get
> confused about which one is tracking what. Thanks everyone!

I don't think that we need a new report.  At least for my case the issue is described well in
https://bugs.kde.org/show_bug.cgi?id=491421
for Plasma-6.1.3, incl. the empty session after renewed login.  And I confirm that for patched plasma-workspace-5.27.11.1.

Also see comment  https://bugs.kde.org/show_bug.cgi?id=488520#c3  and following.

(In reply to imaginator from comment #62)
> (In reply to Nate Graham from comment #60)
> > Yep. A new bug report would be helpful here, since clearly there are
> > multiple issues. Each one needs its own bug report so we don't all get
> > confused about which one is tracking what. Thanks everyone!
> 
> I don't think that we need a new report.  At least for my case the issue is
> described well in
> https://bugs.kde.org/show_bug.cgi?id=491421
> for Plasma-6.1.3, incl. the empty session after renewed login.  And I
> confirm that for patched plasma-workspace-5.27.11.1.
> 
> Also see comment  https://bugs.kde.org/show_bug.cgi?id=488520#c3  and
> following.

I think it is better described here:
https://bugs.kde.org/show_bug.cgi?id=491130

So above bugs are duplicates.

(In reply to David Edmundson from comment #58)
> >You should at least explain what the problem was and how it was fixed
> 
> The original bug report is about ICE, which is a duplicate of 487912 and
> fixed by plasma-workspace 0dcf34458d99b07a3d9054ae0c86c656e0dfa7aa

Or perhaps it was _not_ fixed.  I checked sys.log and found the following which was definitely with a successfully patched plasma-workspace-5.27.11.1 (I keep  build-logs):

[...]
Sep 10 20:03:09 NN xembedsniproxy: Qt: Session management error: Authentication Rejected, reason : MIT-MAGIC-COOKIE-1 authentication rejected
Sep 10 20:03:09 NN polkit-kde-authentication-agent-1: Qt: Session management error: Authentication Rejected, reason : MIT-MAGIC-COOKIE-1 authentication rejected
Sep 10 20:03:09 NN plasmashell: Qt: Session management error: Authentication Rejected, reason : MIT-MAGIC-COOKIE-1 authentication rejected
[...}
Sep 10 20:03:11 NN kate: Qt: Session management error: Authentication Rejected, reason : MIT-MAGIC-COOKIE-1 authentication rejected
Sep 10 20:03:17 NN konsole: Qt: Session management error: Authentication Rejected, reason : MIT-MAGIC-COOKIE-1 authentication rejected
Sep 10 20:03:21 NN konsole: Qt: Session management error: Authentication Rejected, reason : MIT-MAGIC-COOKIE-1 authentication rejected
Sep 10 20:03:23 NN okular: Qt: Session management error: Authentication Rejected, reason : MIT-MAGIC-COOKIE-1 authentication rejected
[...]

This happened after I had manually edited  .config/kglobalshortcutsrc  (outcommented two seemingly identical values).  Before that there were two successful restores, one after logout/login, one after reboot.

Similar error-messages are in the log for Sept. 23 and 26 but I can't recall the circumstances.

(In reply to Aleksey Kontsevich from comment #63)
> (In reply to imaginator from comment #62)
> > (In reply to Nate Graham from comment #60)
> > > Yep. A new bug report would be helpful here, since clearly there are
> > > multiple issues. Each one needs its own bug report so we don't all get
> > > confused about which one is tracking what. Thanks everyone!
> > 
> > I don't think that we need a new report.  At least for my case the issue is
> > described well in
> > https://bugs.kde.org/show_bug.cgi?id=491421
> > for Plasma-6.1.3, incl. the empty session after renewed login.  And I
> > confirm that for patched plasma-workspace-5.27.11.1.
> > 
> > Also see comment  https://bugs.kde.org/show_bug.cgi?id=488520#c3  and
> > following.
> 
> I think it is better described here:
> https://bugs.kde.org/show_bug.cgi?id=491130
> 
> So above bugs are duplicates.

Seems so.  Let the officials sort out what's the original and what's the duplicate.

>https://bugs.kde.org/show_bug.cgi?id=491130

We can trace things with Plasma 6.1 specifically about 'MIT-MAGIC-COOKIE-1 authentication rejected' there.

(In reply to imaginator from comment #53)
> (In reply to zb4ng from comment #52)
> > (In reply to Ondrej Mosnáček from comment #45)
> > > I haven't seen this for a while but if you encounter it often you could try
> > > to avoid losing your session by switching to "Restore from manually saved
> > > session" in systemsettings and then use the session-menu to manually save
> > > your session 
> > Tried this, but, unfortunately, doesn't help.
> Sorry to hear that.  I've tested it with Plasma-5.27.11 where it works. 
My apologies! I made a mistake at last time.    
Today, it happened again and the workaround did help: I had previously saved the state with "Save Session". Now the bug happened. Then I  rebooted and this restored the session!
Thanks!