This post is basically for KDE Plasma users on Linux systems which are not based on rolling releases, but which get upgraded in the course of defined upgrade cycles of the distribution. It is a kind of reminder about a rather trivial point when you upgrade your Linux system or when someone else has done this for you:

• It may sometimes be worth the effort to rebuild and reconfigure your KDE Plasma desktop after your Linux OS has been upgraded.

A full upgrade of a modern Linux system comprises the upgrade of very different components. In most cases a change to a newer version of your preferred desktop environment is part of the packet upgrades. Regarding the evolution of KDE/Plasma during the last 20 years, I have several times experienced that the desktop may exhibit problems after such an upgrade. In a few cases the desktop itself and its configuration would struggle with problems, sometimes a certain application or plasmoid had deficits. Such deficits have most often affected the performance or presentation of only the application on the desktop, but sometimes the overall desktop performance was hampered.

Startup times for standard Linux systems are pretty fast these days – including the start of a graphical desktop session. Even on a 12 years old laptop a KDE Plasma desktop based on X11 builds up within 3 secs after passing login credentials – even with reconstructing the status of multiple applications you left open at the end of your last KDE session. Part of the time may go into (Wifi) network access – and the establishment of complex firewall rules during network startup by networkmanager – dependent on your configuration. But under normal circumstances, establishing network connections by networkmanager should not be an obstacle for a fast general start of the graphical desktop.

Therefore, it should make you nervous when you find that starting a KDE Plasma session on a laptop takes around 10 to 20 secs. This was an experience I yesterday had on a system which had been upgraded to Opensuse Leap 15.6 some months ago. The user was frustrated about a long delay during KDE startup – which he could prove by excerpts of logged system messages. Unfortunately, neither the system logs nor the X11 logs indicated clearly what the reason was. In my opinion, this was an indication of some problematic configuration. Even if the KDE desktop appeared to work without problems after its long startup phase. Some app or plasmoid could have waited during the start of the desktop session for a rather long period for a timeout.

I could help my acquaintance. The question who has caused the glitch, the user or the OS provider, most often is relatively unproductive and fruitless. As long as there is no indication of a hacker’s manipulation … Leaving the possibility of a hacker’s interference aside, we first of all want to reconstruct a working graphical environment. If we find the culprit for the problems on our way – the better it is. Nevertheless, for important system exposed for whatever reason to unfriendly attackers, I would recommend to make forensic copies of the system first. Never ever think, Linux is a kind of barrier for experienced hackers …

This post, therefore, is about a possible solution under best circumstances – namely about a systematic reconstruction of your KDE desktop, its layout, plasmoids and applications to avoid configuration “errors” you may have carried around with you since the last or even since some older upgrade.

What steps should you try when noticing long KDE Plasma startups ?

The first point is to have a reasonable comparison and respective data. The given startup-time for present KDE-versions t_start < 3 secs even for very old systems must be taken with a grain of salt as the startup may strongly depend on certain plasmoids or on the immediate success of starting applications to build up connections to servers.

To find out whether your KDE desktop would start fast with a standard setup – i.e. without special configurations in place and/or without e.g. your email or other major applications activated in the background, you may want to follow the steps listed below:

• Create a new dummy or test user account and start his/her yet unconfigured desktop. (By the way: Also in other contexts it may be convenient to have a plain dummy user account on your Linux system for tests. But, of course, take the same general security measures for this user as for productive ones. In particular regarding passwords and access rights to internal or external resources.)
• Adjust the general desktop layout of the test user to closely reflect the settings of your productive account => background, window behavior, control panel(s) and its (their) basic elements – but no additional plasmoids or applications, yet. Measure the startup time.
• If the startup time is short, start adding plasmoids in a 2nd session. Test the startup time of the dummy user’s desktop again and compare it the startup time of your own productive account.
• When you use networkmanager to control your network access on a user specific basis, reproduce your connection settings (you may need admin rights to do it properly) and check the startup time afterward. (A user specific configuration should not be required for global network access settings of networkmanager configured by the administrator of your system.)

Let us assume, you now can exclude that a certain newly configured plasmoid or basic elements of the desktop is responsible for the discrepancy in startup times. But, with this result, you have only achieved a relatively solid basis for further analysis. We just have found out now that for a new user account the basic desktop starts fast enough with a certain standard configuration of its elements.

Backup copies ahead of further experiments !

When you have come so far and the discrepancy in startup times is still big but cannot be related to a specific plasmoid or network access, you must dig a bit deeper. The next steps require a new setup of the KDE Plasma desktop for your productive user account. And in turn this step requires some backup measures:

• In case you have the suspicion that your desktop environment has been manipulated by attackers, a forensic backup of your whole Linux system is required for proper analysis. Ask a Linux consultant for help in this situation.
• Ahead of further experiments, first make at least a copy of the “.config”-folder, which you find in your home-directory, and transfer it to a secure place on or outside of your Linux system. Perform the copy as root with “cp -dpRv” to keep all access-right assignments to the files/folders as they were.
• To be prepared for all eventualities also put a backup of your whole home-directory onto an external medium. Do not underestimate the risk of loosing important configuration and user related information for browsers and other important applications (as e.g. groupware) during experiments … even access information to some resources may be affected by carelessness. In short: Be prepared to reconstruct the complete present state of your user account if something goes wrong.

I assume that you have created the necessary backups. Now, perform the following step:

• Open a KDE Plasma desktop session for your productive account. Then rename your “.config”-folder, log out of your desktop session and log in again. KDE will automatically recreate the “.config”-folder with required standard entries in files and sub-folders. Compare the desktop startup-time now with your previously measured startup-time.

If your startup time for the KDE Plasma session has improved substantially, already, you know that the culprit is some misconfiguration – which may have been caused by the upgrade itself and not because you have done something wrong.

If you have come that far, your additional work is probably rather limited. If, however, your startup time has not improved, you may be in deeper trouble. A recovery of a proper functionality of your account requires a lot more steps and detailed analysis. There is no real standard recipe for this. Just using a new and fresh user account will not help – because you have to juggle in addition with your user- and group IDs. Your rights on the system (and on servers) will (may) depend on these IDs. I am not going into the required steps in this post.

So, let us assume that the automatic recreation of your “.config”-folder helped – and improved your KDE startup time significantly.

Check differences in the networkmanager and its plasmoid components settings first

An “application” which plays a crucial role during KDE’s startup on a normal desktop is “networkmanager” and its frontends for KDE/Plasma. Networkmanager appears both in form of a daemon and in form of associated frontends – like plasmoids and respective mini-programs in the system control part of the desktop’s control panel (or in multiple control panels on different physical desktop screens).

Network configuration is more difficult these days then ever. I, personally, recommend that any private user of a singular Linux systems should deactivate all IPv6 components and settings. Take this as a clear advice (which I will certainly get much criticism for):

• Deactivate IPv6 – if you are not an expert and if you do not know exactly what you, your routers and your firewall(s) are doing on a low level with IPv6. IPv6 can turn your Internet connection into a hell for you.

If you are using “networkmanager” as a standard Linux consumer, go to the IPv6 panels of its configuration interface offered by some standard symbol in the system control tray. Check your settings there. Set IPv6 to “deactivated” if you are a standard user. Otherwise have a talk with your administrator.

The backup of your “.config”-directory may contain respective configuration files – e.g. “plasma-nm” – and – oh wonder – the “.config”-directory of your fresh dummy user account may not. Despite the fact that you have already re-established your network connections again. Well , you may already have identified a part of your problems.

Stepwise recreation of your application specific settings

The following step requires a bit of experience and thinking. The basic idea is to successively add the settings for certain applications or groups of selected applications to your freshly recreated “.config”. This can be achieved by step-wise adding and overwriting the new settings element for element from your backup-copy – and afterwards retesting startup-times.

• Make a copy of your presently working “.config” contents. Just to save reconstruction time of the achieved state in case that the next step restores trouble.
• Select a limited group of probably connected files and folders in the backup of your original “.config” and copy them to your new “.config”-folder – overwriting the present entries. Then log-out from your session, login again and measure startup times.
• If startup-times remain short, you have regained your old settings for the application, but not yet found the culprit. Continue with the next group of folders/files for settings.
• Keep, however, settings in the subfolders “kdedefaults”, “KDE” and all files starting with “plasma…” as they are, for the time being.

One has, however, to select carefully what you add in each step – as certain applications may not work independently of each other. If you for example used kwallet for password saving, the kwallet settings should be reconfigured ahead of other settings for applications which access kwallet. Another point is email. KDE’s PIM “kontact” and/or kmail work together with Akonadi, which manages and synchronizes resources in the background. And all these applications are controlled by settings distributed over both certain files and specific sub-folders of the “.config”-directory.

The last four steps give you a chance both to reconstruct your original working environment – and at the same time maybe find the culprit for your trouble.

When you come to the point that only plasma-related files/folders have remained, you may simply stop your investigation. You probably have reconstructed all your desktop properties in a reasonable way. (Well, pulseaudio – if you use it – is always good for a surprise …). The rest contains most likely a problematic setting kept since older version of KDE/Plasma.

But for those who like to go to the bottom, some settings in these plasma-related files/folders may be interesting. Then take a deeper look and compare the contents of all these files.

Conclusion

Problems with long startup times for your KDE Plasma desktop can be the result of problematic settings carried with you from older versions of your Linux distribution. In many cases a systematic reconstruction of your “~/.config”-directory may help to overcome the obstacles – and your KDE/Plasma desktop may start up and run faster than ever before.