Version: 4.3.4 (using KDE 4.3.4) OS: Linux Installed from: Fedora RPMs my default screen saver is the blank screen from kde. i have noticed that if i let the screen saver lock automatically and i unlock it manually several times a day, i will find several instances of kblankscrn.kss in memory killing these instances has no detrimental impact to the machines performance as far as i can see.
I am experiencing something similar. I don't have screen saver enabled (start automatically is off). However, I am using 'switch user' functionality quite a lot, changing between two always logged in users. Every time I do user switch, there is the kscreenlocker waiting for user to type password. I guess in this step the kblankscrn.kss is used to set background blank. After a while of user switches, there are a lot of those kblankscrn.kss instances which are not using CPU but of course eat some memory. I have also noticed that the user switching is getting slower the more I do it. Maybe those extra processes are affecting here. I am running KDE 4.4 RC2 on Kubuntu.
I have the same issue, but with KDE 4.10 on Gentoo. # ps -A | grep kblankscrn 4652 ? 00:00:00 kblankscrn.kss 4653 ? 00:00:00 kblankscrn.kss 5114 ? 00:00:00 kblankscrn.kss 5136 ? 00:00:00 kblankscrn.kss 6265 ? 00:00:00 kblankscrn.kss 6266 ? 00:00:00 kblankscrn.kss 24467 ? 00:00:01 kblankscrn.kss 24468 ? 00:00:01 kblankscrn.kss 29964 ? 00:00:00 kblankscrn.kss 29965 ? 00:00:00 kblankscrn.kss 30372 ? 00:00:01 kblankscrn.kss 30373 ? 00:00:01 kblankscrn.kss
Git commit bbb408803965c70fc2cdadadbc08f17bce4cfade by Aaron Seigo. Committed on 12/03/2013 at 20:16. Pushed by aseigo into branch 'KDE/4.10'. actually STOP the screen saver Related: bug 314859 M +1 -0 ksmserver/screenlocker/greeter/screensaverwindow.cpp http://commits.kde.org/kde-workspace/bbb408803965c70fc2cdadadbc08f17bce4cfade
Git commit ee003f90c6251e8c73928127ab91945fc46fa3a0 by Aaron Seigo. Committed on 12/03/2013 at 20:16. Pushed by aseigo into branch 'master'. actually STOP the screen saver Related: bug 314859 M +1 -0 ksmserver/screenlocker/greeter/screensaverwindow.cpp http://commits.kde.org/kde-workspace/ee003f90c6251e8c73928127ab91945fc46fa3a0
Thanks so much for fixing this! Looks like it will save me more than 100 MB of RAM after a while of suspending and resuming.
Based on bug #14859 comment #5 onwards, this is not really fixed. Looks to me like we leak legacy screensaver processes when the screenlocker process dies - i.e. when it quits (due to unlock), crashes (due to bugs etc.) or is killed (by the grace time unlocking in lockwindow.cpp). Not sure what the best way to deal with this is?
(In reply to comment #6) > Based on bug #14859 comment #5 onwards That's bug #314859 comment #5 of course.
I could reproduce this with kblankscrn.kss and kswarm.kss as written in bug #314859. (with those 2 this happens every time) With others this didn'nt happen yet for me. I haven't tried all I must say, but I have set my screensaver to random...
This will happen with any legacy screensaver - the problem is in the kde screenlocker code.
Ah ok. I just wanted to provide clues, as it is not happening with _all_ screensavers...
(In reply to comment #5) > Thanks so much for fixing this! Looks like it will save me more than 100 MB > of RAM after a while of suspending and resuming. Sorry for my inaccurate report. This bug is definitely not fixed, and I just killed off about 50 kblankscrn.kss process...
As a dirty hack / workaround, I changed my screensaver to the clock, and set all the colors of the clock elements to black. So I now have a blank screen that doesn't seem to create multiple hanging processes.
I just tested KDE 4.11 Beta 1 and this bug is still there...
In my case the screensaver is configured to automatically show after 2 minutes and require the password after 150 seconds. The process seems to exit fine when the screen saver is unlocked entering the password. If i however stop the screensaver by pressing any key before i have the enter the password i have an extra 2 processes that keep running.
Bug still exists in KDE 4.10.4 on Gentoo. I can verify what k.neumayer said. if the screen-saver exits before password is required, kblankscrn.kss persists in background. This behavior stacks for each execution of the screen-saver.
I just refer to my comment there: https://bugs.kde.org/show_bug.cgi?id=314859#c36 Is there really a sense in keeping two duplicate bugs open, if nobody cares for either of them? Sorry if I sound a bit desperate, but we'll soon have 4.11 and this was reported against 4.10...
And I'm raising the priority here as well... You know why.
Ah well, I usually dislike voting for newer duplicate bugentries but did so nevertheless... maybe they will fix it at some point... hopefully... - f0o
*** Bug 326789 has been marked as a duplicate of this bug. ***
Similar symptoms happen here with KDE 4.11.2 on Kubuntu 13.10. After a period of time, multiple processes *.kss occur (shown in top), matching the selected screen saver. After shutdown and login, there are multiple blank black windows, with *.kss name. I hadn't noticed this behaviour when running Kubuntu 13.04 or earlier on this box.
Same here, Kubuntu 13.10, only I use OpenGL screensavers which eat considerable CPU time and heat up the laptop (reducing battery life etc).
(In reply to comment #20) > Similar symptoms happen here with KDE 4.11.2 on Kubuntu 13.10. > After a period of time, multiple processes *.kss occur (shown in top), > matching the selected screen saver. After shutdown and login, there are > multiple blank black windows, with *.kss name. > I hadn't noticed this behaviour when running Kubuntu 13.04 or earlier on > this box. Kubuntu 13.10 , the password unlock screen shows up, but as I move the mouse it unlocks itself. Home pc so I never bothered to fix that, but after some time the computer (old and cranky) gets unusable to the point I need to reboot. Upon reboot I have 50 *.kss screen saver windows open. While a spectacular visual effect, not really useful : /. I will fix the password part for now I guess.
(In reply to comment #22) > Kubuntu 13.10 , the password unlock screen shows up, but as I move the mouse > it unlocks itself. This is another bug (also in there since 4.10) that got fixed recently: The screen locker shows the password request screen, even though no password is required. And the default is to _not_ require a password to unlock, see systemsettings->Display and Monitor->Screen Locker. For a workaround to the issue with those windows appearing on login, see the other bug report: https://bugs.kde.org/show_bug.cgi?id=314859#c42
Monitor the proper bug for the next several years while the problem languishes and languishes...
Hi, Until the issue is finally resolved, I wrote a small script that you may find useful. The script looks for kslideshow.kss processes that have started to run more than 30 minutes ago and kills them, to prevent their accumulation. Since my system is configured to turn the screen off after 30 minutes, I don't have any use to any screensaver processes running more than this amout of time. If your screen locker is set to require a password it will work even if the .kss process has been killed so no need to worry about that. The script is written in Ruby, save it with executable permissions and add it to the auto-startup list of processes and you're done (or you can remove the "while true" loop and use a cron to run it every set amount of time. Here it is: #! /usr/bin/ruby MAX_TIME_SINCE_START = 1800 begin curr_time = Time.new.to_i kslideshow_processes_list = `pgrep kslideshow.kss`.split("\n") kslideshow_processes_list.each { |kslideshow_process| kslideshow_process.strip! ps_result = `ps -p #{kslideshow_process} -o lstart` process_start_date = `ps -p #{kslideshow_process} -o lstart`.split("\n")[1].strip get_date_command = "date -d \"#{process_start_date}\" +\"%s\"" kslideshow_start_time = `#{get_date_command}`.to_i time_since_started = curr_time - kslideshow_start_time if time_since_started > MAX_TIME_SINCE_START system( "kill #{kslideshow_process}" ) end } sleep MAX_TIME_SINCE_START end while true Note that if you're using another screensaver and not kslideshow you need to change the name in the pgrep command. Also, set the MAX_TIME_SINCE_START constant per your preferences. Ruby is installed on most systems under /usr/bin/ruby but make sure this is also the case for you.
*** Bug 330229 has been marked as a duplicate of this bug. ***
(In reply to comment #25) > Hi, > > Until the issue is finally resolved, I wrote a small script that you may > find useful. The script looks for kslideshow.kss processes that have > started to run more than 30 minutes ago and kills them, to prevent their > accumulation. Since my system is configured to turn the screen off after 30 > minutes, I don't have any use to any screensaver processes running more than > this amout of time. If your screen locker is set to require a password it > will work even if the .kss process has been killed so no need to worry about > that. The script is written in Ruby, save it with executable permissions > and add it to the auto-startup list of processes and you're done (or you can > remove the "while true" loop and use a cron to run it every set amount of > time. Here it is: > > #! /usr/bin/ruby > MAX_TIME_SINCE_START = 1800 > begin > curr_time = Time.new.to_i > kslideshow_processes_list = `pgrep kslideshow.kss`.split("\n") > kslideshow_processes_list.each { |kslideshow_process| > kslideshow_process.strip! > ps_result = `ps -p #{kslideshow_process} -o lstart` > process_start_date = `ps -p #{kslideshow_process} -o > lstart`.split("\n")[1].strip > get_date_command = "date -d \"#{process_start_date}\" +\"%s\"" > kslideshow_start_time = `#{get_date_command}`.to_i > time_since_started = curr_time - kslideshow_start_time > if time_since_started > MAX_TIME_SINCE_START > system( "kill #{kslideshow_process}" ) > end > } > sleep MAX_TIME_SINCE_START > end while true > > Note that if you're using another screensaver and not kslideshow you need to > change the name in the pgrep command. Also, set the MAX_TIME_SINCE_START > constant per your preferences. Ruby is installed on most systems under > /usr/bin/ruby but make sure this is also the case for you. Had to remove the .kss from the line kslideshow_processes_list = `pgrep kdeasciiaquarium.kss`.split("\n") to get this to work
This bug report recently had it's 4th birthday... /home/mhaase $ ps aux | grep kdeasciiquarium | wc -l 24 Is this really such a complicated issue???
Wouldn't be a problem for me apart from the fact that having 2 kdeacsiiquarium screen savers running causes the screen to flicker,
Created attachment 85183 [details] Konsole screenshot of htop showing kslideshow.kss still running after being stopped I can confirm this. I'm using the latest version 4.12.1, and it's still the same. All screensaver processes keep running after the screensaver has stopped. I'm using only the "Slideshow" screensaver (kslideshow.kss). After the screensaver has stopped, it's not displayed anymore, but the process keeps running in the background and pointlessly wastes cpu and memory ressources. If the screensaver has been running multiple times during a session, then multiple screensaver processes add up. See the Konsole screenshot of htop, where "kslideshow.kss" is hogging a whopping 30% of the cpu ressources, as well as 350 MB of virtual memory and 85 MB of physical memory, a good while after the screensaver has stopped! It would be highly desirable if someone fixed this bug, so that the screensaver process is terminated once it stops, instead of keeping running in the background. That way, I wouldn't have to kill the screensaver processes myself all the time using System Monitor or htop.
Didn't mention it above, but I'm running Kubuntu 13.10 with the latest updates, and I'm using the Kubuntu backports repository. (In reply to comment #25) > Hi, > > Until the issue is finally resolved, I wrote a small script that you may > find useful. The script looks for kslideshow.kss processes that have > started to run more than 30 minutes ago and kills them, to prevent their > accumulation. Since my system is configured to turn the screen off after 30 > minutes, I don't have any use to any screensaver processes running more than > this amout of time. If your screen locker is set to require a password it > will work even if the .kss process has been killed so no need to worry about > that. The script is written in Ruby, save it with executable permissions > and add it to the auto-startup list of processes and you're done (or you can > remove the "while true" loop and use a cron to run it every set amount of > time. Here it is: <snip> I've got no experience with crons... How do I have to change the script so that it runs once an hour?
Same issue as some others in this thread, Kubuntu 13.10, KDE 4.11.5. Dual monitors, and running kdeasciiquarium as my screensaver from the Screen Locker systems settings. After a while, I have a system doing this: ps aux | grep asci russlewi 6795 17.6 0.5 306264 43868 ? S Mar17 278:24 kdeasciiquarium.kss -window-id 54526022 russlewi 6796 19.1 0.5 308488 46112 ? S Mar17 302:07 kdeasciiquarium.kss -window-id 54526045 russlewi 15806 13.6 0.5 306548 44072 ? S 11:32 52:33 kdeasciiquarium.kss -window-id 41943110 russlewi 15807 14.2 0.5 308144 45816 ? S 11:32 54:37 kdeasciiquarium.kss -window-id 41943133 russlewi 16745 1.8 1.1 360784 97940 ? S 15:18 2:55 kdeasciiquarium.kss -window-id 41943110 russlewi 19453 13.7 0.5 304536 42076 ? S 17:56 0:01 kdeasciiquarium.kss -window-id 41943110 russlewi 19454 13.9 0.5 305832 43476 ? S 17:56 0:01 kdeasciiquarium.kss -window-id 41943133
I noticed some time ago that the screen savers do not stay in memory when I need to type in a password to unlock the screen. Can somebody else try this and report whether or not this is the same for him/her? (either activate "Require Password after", or lock the screen manually) I might have found the reason for this issue: The screenlocker runs "kscreenlocker_greet" which shows the background picture (and the password input field if needed). This in turn runs the configured screensaver as a separate process. When the screen is unlocked by entering the password, kscreenlocker_greet exits gracefully (and terminates the screensaver process). If no password is needed, it is forcefully killed by the screenlocker. Apparently this can leave behind the screensaver process, although I don't quite understand why it doesn't happen with _every_ screensaver then. I do have a patch ready that fixes the problem for me (by telling kscreenlocker_greet to exit gracefully even when no password is needed). I tested it a few hours now with kblankscreen.kss and kswarm.kss, which both consistently stayed in memory here before, and the screensaver process didn't stay in memory one single time.
(In reply to comment #33) > I noticed some time ago that the screen savers do not stay in memory when I > need to type in a password to unlock the screen. > > Can somebody else try this and report whether or not this is the same for > him/her? (either activate "Require Password after", or lock the screen > manually) Yes, using Kubuntu Trusty Beta with KBlankscreen 4.11.8 and KDE 4.12.95 I set the Screen Locker to start automatically after 1 minute and require password after 10 seconds. When the password is required (after the timeout, or manually locking the screen), no screensaver process remains. If I hit the keyboard when the screensaver starts, before the password is required, a kblankscrn.kss process does remain afterwards.
(In reply to comment #34) > Yes, using Kubuntu Trusty Beta with KBlankscreen 4.11.8 and KDE 4.12.95 I > set the Screen Locker to start automatically after 1 minute and require > password after 10 seconds. When the password is required (after the timeout, > or manually locking the screen), no screensaver process remains. If I hit > the keyboard when the screensaver starts, before the password is required, a > kblankscrn.kss process does remain afterwards. Thanks for the confirmation. I'm pretty sure that my patch would fix the issue for you then, too. But I really would like to have some feedback from at least one of the other posters in this bug report as well, please.
I can confirm the following behavior in KDE 4.11.3 with these settings: X Start automatically after (1 minute) X Require password after (10 seconds) If I interrupt/wake the screen after 1 minute but before 70 seconds no password dialog is presented, and an "orphan" kblankscrn.kss process gets left behind. If I wait 70+ seconds, I receive a login dialog and there is no orphan process. I do not normally use the "Require password after" setting at all, I just leave it unchecked, and the orphan processes really build up. I had observed in the past that when I manually trigger the screen lock/password with CTRL+ALT+L, there was never an orphan process left behind. On another note, I'm not a big fan of the terminology "screen locker" here. Why not just screen saver, like everyone is used to? (In reply to comment #35) > (In reply to comment #34) > > Yes, using Kubuntu Trusty Beta with KBlankscreen 4.11.8 and KDE 4.12.95 I > > set the Screen Locker to start automatically after 1 minute and require > > password after 10 seconds. When the password is required (after the timeout, > > or manually locking the screen), no screensaver process remains. If I hit > > the keyboard when the screensaver starts, before the password is required, a > > kblankscrn.kss process does remain afterwards. > Thanks for the confirmation. > I'm pretty sure that my patch would fix the issue for you then, too. > > But I really would like to have some feedback from at least one of the other > posters in this bug report as well, please. I can confirm the following behavior in KDE 4.11.3 with these settings: X Start automatically after (1 minute) X Require password after (10 seconds) If I interrupt/wake the screen after 1 minute but before 70 seconds, no password dialog is presented and an "orphan" kblankscrn.kss process gets left behind. If I wait 70+ seconds, I receive a login dialog and there is no orphan process. I don't normally use the "Require password after" setting at all (I just leave it unchecked) and the orphan processes really build up. I had observed in the past that when I manually trigger the screen lock w/password with CTRL+ALT+L, there was never an orphan process left behind. Side note, I'm not a big fan of the terminology "screen locker" for this functionality. Why not just screen saver, like everyone is used to?
The bug sadly is still alive and kicking in 4.13.
(In reply to comment #37) > The bug sadly is still alive and kicking in 4.13. There is no kde-workspace 4.13 and KDE SC 4.13 does not include a new kde-workspace at all. The next kde-workspace release will be 4.11.9, scheduled for April 29th. Instead of stating the obvious here, you better should have tried what I asked in comment#33 and report your result. As I said, I have a patch ready that fixes the problem for me, it is already part of openSUSE's packages. But this will have to wait until https://git.reviewboard.kde.org/r/117091/ is in, as it touches the same parts of the code. (and that bug fix is much more important IMHO) (In reply to comment #36) > I can confirm the following behavior in KDE 4.11.3 with these settings: Thank you too for verifying and confirming. > Side note, I'm not a big fan of the terminology "screen locker" for this > functionality. Why not just screen saver, like everyone is used to? Well, I used the differate terms on purpose to distinguish between those different things. Btw, the screen locker locks the screen, it does NOT "save" the screen. And there are 3 possible configurations atm, namely the "simple screen locker", the "legacy screen saver", and plasma widgets. Anyway, my explanation would not have been comprehensible if I had used "screen saver" instead of "screen locker", don't you agree? "The screen saver runs "kscreenlocker_greet"... This in turn runs the configured screen saver as a separate process." and so on. ;-)
(In reply to comment #38) > (In reply to comment #37) > > Side note, I'm not a big fan of the terminology "screen locker" for this > > functionality. Why not just screen saver, like everyone is used to? > Well, I used the differate terms on purpose to distinguish between those > different things. fwiw, I like the terminology "screen locker". It is accurate and clear.
Maybe I don't know what "screen locker" really means, but it appears to display after a few minutes of inactivity, even when the screen isn't "locked". E.g. if I wiggle the mouse then it goes away, without needing a password.
(In reply to comment #40) > Maybe I don't know what "screen locker" really means, but it appears to > display after a few minutes of inactivity, even when the screen isn't > "locked". E.g. if I wiggle the mouse then it goes away, without needing a > password. Yes, that's because the screen locker has a "grace time" in which no password is needed (can even be infinite, if you disable "Require password after" in the settings). But please! Let's stop discussing the name of that thing here in this bug report. That's just ridiculous and futile anyway.
(In reply to comment #40) > Maybe I don't know what "screen locker" really means, but it appears to > display after a few minutes of inactivity, even when the screen isn't > "locked". E.g. if I wiggle the mouse then it goes away, without needing a > password. Beat me to it. I don't use the "locker" functionality at all. FWIW, I get it, but I do wonder if it might cause some confusion in a new users. Personally, I'd just call it a screen saver and the "lock" function "enable password prompt" or something. Apologies, Wolfgang, I'll let drop.
*** Bug 323064 has been marked as a duplicate of this bug. ***
*** Bug 326701 has been marked as a duplicate of this bug. ***
*** Bug 333140 has been marked as a duplicate of this bug. ***
I confirm that I suffer from this same bug with various screensavers, and indeed the process is left behind only if the password lock did NOT occure.
The same here with a fresh installed Kubuntu 14.04. multiple instances of "kclock.kss" in memory. The screensaver does'nt work - intead a blank wallpaper-screen apears. Its frustrating. After years and multiple OS versions still the same mess. (shakes head ...) Greets
(In reply to comment #47) > The same here with a fresh installed Kubuntu 14.04. multiple instances of > "kclock.kss" in memory. Is it fixed when you have to enter a password? I.e. enable "Password required after" and set it to 1s f.e. > The screensaver does'nt work - intead a blank > wallpaper-screen apears. That's a completely different problem. Sounds like https://bugs.kde.org/show_bug.cgi?id=305781 Try to disable the option "Suspend desktop effects for fullscreen windows" in the Desktop Effects settings ("Advanced"). > Its frustrating. After years and multiple OS versions still the same mess. (shakes head ...) If the clock screensaver doesn't work for you anyway, why don't you just use the "Simple Screenlocker", as is the default? That one doesn't have this problem... ;)
(In reply to comment #48) > Sounds like https://bugs.kde.org/show_bug.cgi?id=305781 Oops, sorry, Wrong link. It's this bug that I meant: https://bugs.kde.org/show_bug.cgi?id=317156
FYI, I uploaded my patch to reviewboard now: https://git.reviewboard.kde.org/r/117644/ It's a bit close to the 4.11.9 release, but well let's see, maybe it will still make it... ;)
Git commit 26a8ddc018d940ea1910ced6264344b520ad8405 by Wolfgang Bauer. Committed on 24/04/2014 at 22:25. Pushed by wbauer into branch 'KDE/4.11'. screenlocker: don't leave behind screensaver processes Currently the screen locker just kills the greeter (kscreenlocker_greet) when the screen is unlocked by the user during the grace time. But apparently this can leave behind running screensaver processes launched by the greeter, see the bug report (which has the highest number of votes of all open bugs AFAICS). This patch changes this to only terminate the greeter, and adds a signal handler to the greeter to exit gracefully in this case. The signal handler exits with return code 1, so that it is not possible to circumvent the password input by just sending a SIGTERM. (the screen locker restarts the greeter in case it doesn't quit with exit code 0) FIXED-IN: 4.11.9 REVIEW: 117644 M +13 -1 ksmserver/screenlocker/greeter/main.cpp M +1 -1 ksmserver/screenlocker/ksldapp.cpp http://commits.kde.org/kde-workspace/26a8ddc018d940ea1910ced6264344b520ad8405
Thanks Wolfgang for your fixes! > which has the highest number of votes of all open bugs AFAICS https://bugs.kde.org/buglist.cgi?votes=500&bug_severity=major&bug_severity=grave&bug_severity=normal&bug_severity=crash&bug_severity=critical&bug_status=CONFIRMED&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=UNCONFIRMED&votes_type=greaterthaneq&order=product%2Cbug_id
Git commit b1fa2678d36f6ce215e8d8ec1d57608079f36c89 by Wolfgang Bauer. Committed on 25/04/2014 at 21:02. Pushed by wbauer into branch 'master'. screenlocker: exit greeter gracefully when unlocking during grace time Currently the screen locker just kills the greeter (kscreenlocker_greet) when the screen is unlocked by the user during the grace time. But apparently this can leave behind running screensaver processes launched by the greeter, see the bug report. This patch changes this to only terminate the greeter, and adds a signal handler to the greeter to exit gracefully in this case. The signal handler exits with return code 1, so that it is not possible to circumvent the password input by just sending a SIGTERM. (the screen locker restarts the greeter in case it doesn't quit with exit code 0) REVIEW: 117644 M +13 -1 ksmserver/screenlocker/greeter/main.cpp M +1 -1 ksmserver/screenlocker/ksldapp.cpp http://commits.kde.org/plasma-workspace/b1fa2678d36f6ce215e8d8ec1d57608079f36c89
This is not fixed, using 4.13.0 from Kubuntu x64
@Pierre, my understanding is that it will (probably) land in 4.13.1 http://forum.kde.org/viewtopic.php?f=108&t=121033
Again, it should be fixed in kde-workspace 4.11.9. kde-workspace is versioned independently from the rest of KDE, because its maintainers decided to stay at 4.11.x (it is feature-frozen since 4.11.0 and labelled as LTS release). This has nothing to do with KDE 4.13.0 or 4.13.1. When KDE SC 4.13.0 (and Ubuntu 14.04) was released, the current version has been 4.11.8, which does _not_ include this fix yet. As you should see by looking at the date of the commit (April 24th, whereas Ubuntu 14.04 was released on April 17th and KDE SC 4.13.0 one day earlier). Please ask your distribution for updated packages, or wait until they provide them. They most likely will together with KDE SC 4.13.1 at the latest, but I don't know.
I just noticed the same issue in Kubuntu 14.04 (with kclock.kss). Curiously, it does NOT occur in the 4.11.3 KDE environment available with Linux Mint Debian, which does seem to use the same kscreensaver code. Could that have something to do with the fact I use the proprietary fglrx Radeon driver under LMDE as opposed to the open source driver under Kubuntu?
(In reply to comment #57) > I just noticed the same issue in Kubuntu 14.04 (with kclock.kss). > Again, Kubuntu 14.04 ships kde-workspace 4.11.8, this should be fixed in 4.11.9. I have no idea when (K)Ubuntu releases updated packages, but according to https://launchpad.net/ubuntu/+source/kde-workspace an update for 14.04 is already proposed at least. > Curiously, it does NOT occur in the 4.11.3 KDE environment available with > Linux Mint Debian, which does seem to use the same kscreensaver code. Could > that have something to do with the fact I use the proprietary fglrx Radeon > driver under LMDE as opposed to the open source driver under Kubuntu? Maybe, or maybe it depends on the Xorg version or something else. I have no idea, sorry. On my openSUSE 13.1 systems (one with radeon and one with intel driver) I could only reproduce this issue with kswarm.kss and kblankscrn.kss (I haven't really tried _all_ though, kclock.kss definitely did not stay in memory here). But IMHO _all_ screensavers should actually keep running after unblanking the screen in the grace period. Well, my guess is that they get killed by X/die themselves because some operation they do is now invalid when the screenlocker window is not there any more, or something like that. And that behaviour might differ across distributions/drivers/Xorg versions I suppose.
For all Ubuntu users, I just installed the latest KDE 4.13.1 from the Kubuntu Updates PPA, and it *doesn't* include kde-workspace 4.11.9. $dpkg -l kde-workspace ... kde-workspace 4:4.11.8-0ubuntu6 ...
KDE 4.11.9 is currently in Trusty proposed. Hopefully it will be moved into Trusty once it has been fully tested.