KDE - Nvidia screen corruption after resume

I have had this annoyance for a while on KDE with an Nvidia card. Apparently it is a long standing on and off bug with some Nvidia cards. My desktop icon text is always corrupted after resuming from suspend. Sometimes other window elements are corrupted and are not displayed properly after resuming. I figured it would eventually get fixed, but thought I'd try to fixing it myself. The video corruption can easily be corrected be rebooting, but I rarely reboot.

The video corruption can also be corrected by restarting the plasmashell with the following command:

kquitapp5 plasmashell; kstart5 plasmashell

Or, other commands such as (preferred):

killall plasmashell; plasmashell > /dev/null 2>&1 & disown

An even easier way, is to create a bash alias to simplify running the command. Research the bash alias function to enable this. With a bash alias I only need to enter "restartps" (or whatever you want) to restart the plasmashell.

alias restartps="killall plasmashell; plasmashell > /dev/null 2>&1 & disown"

I thought creating a systemd unit to accomplish this automatically after resuming would be a great way to automate a plasmashell restart. Unfortunately, the systemd service does not fully accomplish this. The service will kill the plasmashell on resume, but no matter what I've tried I can't find a way to automatically restart it. So, after resume I have to manually refresh my desktop by using my alias I created, which is what I'm trying to automate.

I have tested many different systemd options, but have yet to find a solution to successfully starting the plasmashell, (although it will kill the plasmashell correctly after resume).

This is an example of one of my latest systemd unit files.

#sudo systemctl enable restart-plasmashell.service
Description=Restart plasmashell after resuming



I also have tried the "forking" and the "oneshot" options without any more success. I have tested other options as well without improvement.

For ease of editing, I have been using an external script in my home directory. I have tested too numerous of versions to keep track of but still no love. Including the commands in the systemd unit worked no better and only slowed testing as when you update the unit file itself the daemon must be refreshed and the service restarted with root permissions. The external script method is just far easier to edit quickly.

Here are some examples of commands I've tested in the external script:

killall plasmashell; sleep 5; plasmashell > /dev/null 2>&1 & disown

kquitapp5 plasmashell && kstart5 plasmashell > /dev/null 2>&1 & disown

killall plasmashell; sleep 3; kwin_x11 --replace; sleep 5; kstart5 plasmashell & exit 

killall plasmashell; kwin_x11 --replace & kstart5 plasmashell & exit 

killall plasmashell; kstart5 plasmashell     

kbuildsycoca5 && kquitapp5 plasmashell && kstart5 plasmashell 

kbuildsycoca5 && kquitapp5 plasmashell; sleep 3; kwin_x11 --replace; sleep 5; kstart5 plasmashell & exit 

kbuildsycoca5 && kquitapp5 plasmashell && plasmashell > /dev/null 2>&1 & disown

kquitapp5 plasmashell; kstart5 plasmashell

kquitapp5 plasmashell | true && kstart5 plasmashell | true

killall plasmashell | true && kstart5 plasmashell | true

Many of these commands work perfectly when issue from the terminal, but will not initiate a plasma restart correctly via the service.

Any suggestions?


use systemd user and not system

EDIT: but view "note" is a per-user process, and not per-session ?.

I thought that's what this option did?

Thank you for the link. I didn't see it at first as embedded links blend with ither text with the color scheme I use on my browser.

Can you debug the service?

Also, you might use multiple "ExecStart" entries, instead of merged oneliners.
I always wanted to "master" systemd services.. :sweat_smile:

sudo systemctl --user enable plasmashell.service
Failed to connect to bus: No such file or directory

I am just getting into writing services. This solution is far more complicated than I ever suspected when I started. I started writing services a couple of months back, but this one requires a lot of wok to restart plasma.

There are several solutions listed on the wiki, but both involve a lot of extra work. One method requires installing several extra programs from the AUR, the other requires creating several more services.

This seems far more complicated than I ever expected when I started this. I usually enjoy a challenge, but I'm not sure all the extra stuff I need to install and run is worth it. It's beginning to look like my bash alias solution isn't so bad now that I realize how deep this goes to solve this.

ps. I wrote another service that wasn't a typo at the top.

Ya, I did that too. I just included the one liners for brevity.

The complication is starting plasma in the same session with the specified user..

Many thanks to those that responded but I don't think I want to install extra AUR progs or run a bunch of extra services for what is basically just a minor annoyance.

I thought I could solve this easily with a single service file as with others I'd written in the past. Considering all the extra stuff involved I think I'll just consider this solution a dead end.

Thanks again.

I think you should/might not use sudo for user 's admin stuff.

Holy cr@p, your right. I've never initiated a "user" service before.

systemctl --user enable plasmashell.service
Created symlink /home/htpc/.config/systemd/user/suspend.target.wants/plasmashell.service → /home/htpc/.config/systemd/user/plasmashell.service.

Apart from the joy of systemd mastering, would you check if your issues are solved with only kwin restart, instead of whole plasma?

Ya I tried the kwin restart as well. That did not work. I hated systemd with a passion, but now I actually look for excuses to write systemd services to get practice at it. Thank you both. Now I know how to initiate a user service.

The service did start but I have errors as I believe it still hits the wall described on the Achwiki. If I have any luck, I will be sure to report it.

$ systemctl --user status plasmashell.service
● plasmashell.service - Restart plasmashell after resuming
   Loaded: loaded (/home/htpc/.config/systemd/user/plasmashell.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Mon 2018-10-01 18:22:07 MST; 7min ago
  Process: 7569 ExecStart=/home/htpc/.scripts/restartps.sh (code=exited, status=216/GROUP)
 Main PID: 7569 (code=exited, status=216/GROUP)

Oct 01 18:22:07 htpc1 systemd[602]: Started Restart plasmashell after resuming.
Oct 01 18:22:07 htpc1 systemd[7569]: plasmashell.service: Failed to determine supplementary groups: Operation not permitted
Oct 01 18:22:07 htpc1 systemd[7569]: plasmashell.service: Failed at step GROUP spawning /home/htpc/.scripts/restartps.sh: Operation not permitted
Oct 01 18:22:07 htpc1 systemd[602]: plasmashell.service: Main process exited, code=exited, status=216/GROUP
Oct 01 18:22:07 htpc1 systemd[602]: plasmashell.service: Failed with result 'exit-code'.
[htpc@htpc1 ~]$ 

I am going to add "Group=" to the service file to see if that error goes away.

Convert the service to a system service.

systemctl --user status plasmashell.service
● plasmashell.service - Restart plasmashell after resuming
   Loaded: loaded (/home/htpc/.config/systemd/user/plasmashell.service; enabled; vendor preset: enabled)
   Active: inactive (dead)

Error went away after adding the Group entry, but still not working.

I will read your link.

Thank you very much.

Please give your reasoning @AgentS. I was running the service originally as a system service. I tried everything I could think of to get it working that way.

After reading the "user" info on the Archwiki it seemed to be saying this must be initiated as a user service, but that is complex.

As I read in the link, it seems some part if this needs root priv. The solution (?) was to make it a system service and use the User entry.
Just thoughts and searches (in bed) :sweat_smile:

When I grow up, I want to be a SystemD Master!

I will play some more. Truthfully it is only a minor annoyance, but every unit I write I learn a little more. I don't know why, but I actually enjoy playing with systemd units.

Unfortunately I find much of the systemd documentation hard to translate into a working service sometimes.

Wrote 2 unit files to test if unloading/loading the Nvidia drivers pre/post suspend would make any difference.

It didn't.

Oh well, getting lots of practice writing unit files.


@AgentS I have a general question for you. Do you think it's OK to use the ~/.scripts directory for scripts called by "system" units, or should I only have "user" units use the home directory.

I just find it so much quicker (and less hassle) when testing many different options to not have to "sudo" every time I want to test a change. Do you think I should use /scripts for "system" units, and only use ~/.scripts for "user" units. Do you think it matters?

I guess this could be a possible security risk?

Frankly, it doesn't matter IMHO. I understand you are in a self-training mode, so use what's convenient for you for now.
Have in mind, user services are designed so that can be used from all users if possible. Assigning specific character for name (I think it's @), interchange user names. This leads to using also system folders for scripts, or shared folders to all users , or by groups.
First master creating successful smart services, then modify names and folders to a wider scope.
About home folder scripts, I have seen several proposals, like ~/.bin ~/.config/bin ~/.config/scripts and more.

Edit: just take care of permissions

I guess there is a danger that if someone who really knew what they were doing could compromise your system with only user permissions. As the script in the home directory is being executed with root permissions by a systemd unit with system permissions.

So upon further thought I will only use home for testing and Ill use a root directory for the final version. Thank you for your input. I hadn't considered the security risk initially.

1 Like

Well I didn't make much progress with the systemd service to restart Plasma. So, I thought Id take a break on that till my systemd service skills were up to that challenge.

In the meantime, I thought of an even easier way than the bash alias to restart Plasma. Just create a desktop shortcut for this, and place it wherever you find the most convenient.

How to Create A Custom Plasma Restart Desktop File

If either of the following commands are successful then you should be able to easily create a deskop shortcut file to restart Plasma.

kquitapp5 plasmashell; plasmashell > /dev/null 2>&1 & disown


killall plasmashell; plasmashell > /dev/null 2>&1 & disown

You can create a custom desktop start file to initiate a Plasma restart. The desktop file can be placed in your start menu, taskbar, or on your desktop to provide an easy one click icon to restart Plasma.

Create a file named "plasma-restart.desktop" with your text editor.

The desktop file should have the following contents:

[Desktop Entry]
Comment[en_CA]=Restart Plasma.
Comment=Restart Plasma.
Exec=/usr/bin/kquitapp5 plasmashell; plasmashell > /dev/null 2>&1 & disown; sleep 2; exit
GenericName[en_CA]=Restart Plasma
GenericName=Restart Plasma
Name[en_CA]=Restart Plasma
Name=Restart Plasma

Save the file, and then make the newly created desktop file executable.

If you dont like the icon I selected, simply change the entry "Icon=vcs-update-required" to whatever you prefer.

You can place the desktop file in your start menu (~/.local/share/applications), taskbar, or on your desktop.

1 Like

Forum kindly sponsored by