Bug 505151

Thanks for the bug report. Can I ask you for some additional information?

- Does the freeze happen in a Wayland session at all?
- Can you test with a new user with the default panel setup and see if the freeze happens with that user as well? There could be some configuration cruft lying around.

Thanks.

🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME.

For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging.

Thank you for helping us make KDE software even better for everyone!

Sorry for the late reply.
One day after I reported this bugs, it was gone for a week. I was happy and thought it was an update for Fedora which fixed this bug.
Unfortunately the bug was suddenly back. At the moment I have no clue why, how and when the taskbar freezes.

Here what I did so far. Before I reported this bug I reinstalled Fedora and deleted some folders from the user directory like .cache, .config, .kde, .local. I guess this is something simular to "create a new user", hopefully. I couldn't find any useful information in "/var/log/messages".

Some additional information.
- The user directory is mounted as NFS.
- The setting for the taskbar is "Icons-and-Text Task Manager".
- The users are still on X11. I can't tell them to login to Wayland, because Wayland can't restore the session. It's not an option for the users. Sorry for that.
-  When the error occurs and Dolphin is open, I can navigate through the folders in Dolphin. So I can exclude a network problem. It only affects the taskbar.

Is there any way to monitor and log this bug. I would like to provide more information to help the developers.

The user directory being mounted as NFS is probably relevant here. Any network delays, even transient and minor, could translate to the system waiting on a cache or config value to be read.

What I would recommend is to query system logs on a machine for a minute before and after a freeze. Adjust the dates and time in this command to gather that.

journalctl --since "2025-06-10 15:10:00" --until "now"

If you want to save it to a log to attach to this report, you can do something like this

journalctl --since "2025-06-10 15:10:00" --until "now" > ~/log.txt

🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME.

For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging.

Thank you for helping us make KDE software even better for everyone!

Sorry again for the late reply. I have not had access to the computers for the last two weeks.
I will run the journalctl command if the problem occurs again.

(In reply to TraceyC from comment #4)
> The user directory being mounted as NFS is probably relevant here. Any
> network delays, even transient and minor, could translate to the system
> waiting on a cache or config value to be read.
> 
> What I would recommend is to query system logs on a machine for a minute
> before and after a freeze. Adjust the dates and time in this command to
> gather that.
> 
> journalctl --since "2025-06-10 15:10:00" --until "now"
> 
> If you want to save it to a log to attach to this report, you can do
> something like this
> 
> journalctl --since "2025-06-10 15:10:00" --until "now" > ~/log.txt

It's been a while, but it happened again. The system clock in the lower right corner stopped at 15:42:53.
Could this line be important? I don't know.

"xdg-desktop-portal-kde[2499]: kf.config.core: Created a KConfigGroup on an inaccessible config location ..."

Created attachment 183780 [details]
Log from journalctl

> It's been a while, but it happened again. The system clock in the lower
> right corner stopped at 15:42:53.
> Could this line be important? I don't know.
> 
> "xdg-desktop-portal-kde[2499]: kf.config.core: Created a KConfigGroup on an
> inaccessible config location ..."

The system clock is a valuable clue. The time shown when the clock was frozen, 15:42:53, corresponds to the entries in the log:

Aug 04 15:42:33 myhostname xdg-desktop-portal-kde[2499]: kf.config.core: Created a KConfigGroup on an inaccessible config location "/home/ABC/Lif/.directory" "Desktop Entry"
Aug 04 15:42:33 myhostname xdg-desktop-portal-kde[2499]: kf.config.core: Created a KConfigGroup on an inaccessible config location "/home/ABC/Temp/.directory" "Desktop Entry"

That indicates the NFS share was not available at the time KDE was trying to write to it. This would also mean that plasmashell wasn't able to read user preferences and cache values from their home directory.

Unfortunately, if Plasma can't read or write from the user's home directory when it's temporarily inaccessible, that will cause issues like this. The main problem is the user's files being unavailable. This isn't something KDE can fix, you'll need to investigate whatever is causing the /home directory to be randomly inaccessible.

Thank you for your reply and your efforts.
One last question.

The file ".directory" in the folder "/home/ABC/Lif" is not readable or writable for the user experiencing the freezes and the owner is another user. The same here: "/home/ABC/Temp/.directory".

If I'm right, this could be helpful for developers and for users when reporting such a bug.