Bug 224200

Summary: multiple kblankscrn.kss in memory
Product: kscreensaver Reporter: Mohammed Arafa <bugzilla>
Component: generalAssignee: kscreensaver bugs tracking <kscreensaver-bugs-null>
Status: RESOLVED FIXED    
Severity: major CC: aog2000a, bkorb, bugs, carlos, davestechshop, diego.faz, esteaqui, f0o, flyser42, forshopping, ibmalone, ivoras, jynyl, kaysimon, kdebugs, m01brv, mad-eddy, marco.clemencic, mehaase, mfraz74+kde, micha.magen, msmigiel, nick, oliver.henshaw, paul.lemmons, pavelkaroukin, pierre.delagrave, rdieter, rjvbertin, russlewi, sami.nieminen, sb56637, sgmoore, shokushu, tim, wbauer, wvvelzen, zanetu, ziegleka
Priority: HI    
Version: 4.10.0   
Target Milestone: ---   
Platform: Fedora RPMs   
OS: Linux   
See Also: https://bugs.kde.org/show_bug.cgi?id=314859
Latest Commit: Version Fixed In: 4.11.9
Attachments: Konsole screenshot of htop showing kslideshow.kss still running after being stopped

Description Mohammed Arafa 2010-01-25 19:24:13 UTC
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.
Comment 1 Sami Nieminen 2010-01-30 12:42:33 UTC
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.
Comment 2 Pedro 2013-02-21 11:07:14 UTC
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
Comment 3 Aaron J. Seigo 2013-03-12 19:16:54 UTC
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
Comment 4 Aaron J. Seigo 2013-03-12 19:17:27 UTC
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
Comment 5 S 2013-04-04 15:34:51 UTC
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.
Comment 6 Oliver Henshaw 2013-04-15 14:31:37 UTC
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?
Comment 7 Oliver Henshaw 2013-04-15 14:33:17 UTC
(In reply to comment #6)
> Based on bug #14859 comment #5 onwards
That's bug #314859 comment #5 of course.
Comment 8 Wolfgang Bauer 2013-04-15 15:11:27 UTC
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...
Comment 9 Oliver Henshaw 2013-04-15 15:22:22 UTC
This will happen with any legacy screensaver - the problem is in the kde screenlocker code.
Comment 10 Wolfgang Bauer 2013-04-15 15:37:00 UTC
Ah ok.
I just wanted to provide clues, as it is not happening with _all_ screensavers...
Comment 11 S 2013-06-06 13:12:17 UTC
(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...
Comment 12 S 2013-06-06 18:42:20 UTC
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.
Comment 13 Wolfgang Bauer 2013-06-18 13:21:04 UTC
I just tested KDE 4.11 Beta 1 and this bug is still there...
Comment 14 k.neumayer 2013-07-22 13:16:28 UTC
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.
Comment 15 f0o 2013-07-29 09:07:46 UTC
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.
Comment 16 Wolfgang Bauer 2013-08-08 01:27:30 UTC
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...
Comment 17 Wolfgang Bauer 2013-08-08 01:48:29 UTC
And I'm raising the priority here as well...
You know why.
Comment 18 f0o 2013-08-15 09:45:22 UTC
Ah well, I usually dislike voting for newer duplicate bugentries but did so nevertheless...

maybe they will fix it at some point... hopefully...

- f0o
Comment 19 Jekyll Wu 2013-10-29 03:38:05 UTC
*** Bug 326789 has been marked as a duplicate of this bug. ***
Comment 20 Peter Hewett 2013-10-29 08:43:36 UTC
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.
Comment 21 Ivan Voras 2013-11-02 09:06:02 UTC
Same here, Kubuntu 13.10, only I use OpenGL screensavers which eat considerable CPU time and heat up the laptop (reducing battery life etc).
Comment 22 Scarlett Moore 2013-11-27 16:57:40 UTC
(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.
Comment 23 Wolfgang Bauer 2013-11-28 14:27:17 UTC
(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
Comment 24 bkorb 2014-01-04 17:53:09 UTC
Monitor the proper bug for the next several years while the problem languishes and languishes...
Comment 25 Micha 2014-01-08 07:29:34 UTC
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.
Comment 26 Christoph Feck 2014-01-21 04:51:40 UTC
*** Bug 330229 has been marked as a duplicate of this bug. ***
Comment 27 Mark Fraser 2014-01-28 09:35:33 UTC
(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
Comment 28 Mark Haase 2014-01-30 01:12:23 UTC
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???
Comment 29 Mark Fraser 2014-01-30 08:02:26 UTC
Wouldn't be a problem for me apart from the fact that having 2 kdeacsiiquarium screen savers running causes the screen to flicker,
Comment 30 Shokushu 2014-02-16 17:33:18 UTC
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.
Comment 31 Shokushu 2014-02-16 17:59:46 UTC
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?
Comment 32 Russell Lewis 2014-03-18 22:09:01 UTC
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
Comment 33 Wolfgang Bauer 2014-04-01 13:16:35 UTC
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.
Comment 34 Graeme Hewson 2014-04-01 14:50:50 UTC
(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.
Comment 35 Wolfgang Bauer 2014-04-01 20:52:54 UTC
(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.
Comment 36 Peter Yellman 2014-04-03 18:16:48 UTC
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?
Comment 37 Shokushu 2014-04-14 20:06:16 UTC
The bug sadly is still alive and kicking in 4.13.
Comment 38 Wolfgang Bauer 2014-04-15 10:18:52 UTC
(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. ;-)
Comment 39 MountainX 2014-04-15 15:49:55 UTC
(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.
Comment 40 Mark Haase 2014-04-15 17:03:57 UTC
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.
Comment 41 Wolfgang Bauer 2014-04-15 17:53:22 UTC
(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.
Comment 42 Peter Yellman 2014-04-15 18:06:35 UTC
(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.
Comment 43 Wolfgang Bauer 2014-04-17 06:40:48 UTC
*** Bug 323064 has been marked as a duplicate of this bug. ***
Comment 44 Wolfgang Bauer 2014-04-17 06:48:00 UTC
*** Bug 326701 has been marked as a duplicate of this bug. ***
Comment 45 Wolfgang Bauer 2014-04-17 06:50:29 UTC
*** Bug 333140 has been marked as a duplicate of this bug. ***
Comment 46 Roman 2014-04-17 13:01:11 UTC
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.
Comment 47 Olli 2014-04-19 21:58:56 UTC
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
Comment 48 Wolfgang Bauer 2014-04-20 09:58:46 UTC
(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... ;)
Comment 49 Wolfgang Bauer 2014-04-20 10:00:27 UTC
(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
Comment 50 Wolfgang Bauer 2014-04-22 20:21:02 UTC
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... ;)
Comment 51 Wolfgang Bauer 2014-04-24 22:28:34 UTC
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
Comment 53 Wolfgang Bauer 2014-04-25 21:04:09 UTC
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
Comment 54 Pierre Delagrave 2014-05-09 16:59:26 UTC
This is not fixed, using 4.13.0 from Kubuntu x64
Comment 55 sparhawk 2014-05-09 17:11:25 UTC
@Pierre, my understanding is that it will (probably) land in 4.13.1
http://forum.kde.org/viewtopic.php?f=108&t=121033
Comment 56 Wolfgang Bauer 2014-05-10 14:02:25 UTC
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.
Comment 57 RJVB 2014-05-13 21:47:35 UTC
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?
Comment 58 Wolfgang Bauer 2014-05-14 18:26:55 UTC
(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.
Comment 59 sparhawk 2014-05-17 05:44:54 UTC
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
...
Comment 60 Mark Fraser 2014-05-17 07:06:57 UTC
KDE 4.11.9 is currently in Trusty proposed. Hopefully it will be moved into Trusty once it has been fully tested.