Is this still an issue with the latest GIT sources?

The quit call is supposed to quit the screensaver, however with R14 it is normal to have *one* kdesktop_lock process active at all times.  This is a change from 3.5.13.x and below, and was made to mitigate instances where it is impossible to lock a heavily loaded machine due to insufficient resources available to load a new process.  There was a time (until recently) where more than one kdesktop_lock process could exist, however that bug should have been resolved some time ago.

In short, if you see more than one kdesktop_lock process then please let me know how to reproduce that problem, otherwise if you only see one kdesktop_lock process per user after repeated DCOP quit calls then this bug report should be closed.

Closing RESOLVED WORKSFORME as I do not see more than one kdesktop_lock process per user at any time.  Please reopen this report if more than one kdesktop_lock process is noticed per user.

The lock mechanism is not related to this report. :-)

Try the following:

The banner screen saver best illustrates the problem. Before logging in, manually configure the user's kdesktoprc [ScreenSaver]:

Saver=KBanner.desktop
Timeout=10

* Login to start the Trinity desktop.
* Toggle to a different console (Ctrl-Alt-F6).
* Log in (root or user).
* Verify no Trinity screen saver is yet running: ps ax | grep kss

* Wait about 10 seconds.
* Verify only one Trinity screen saver process is running: ps ax | grep kss

* From the console, terminate the kss process: DISPLAY=:0.0 dcop kdesktop KScreensaverIface quit
* Verify the Trinity screen saver is still running: ps ax | grep kss

* Wait about 10 seconds.
* Verify two Trinity screen saver processes are running: ps ax | grep kss

* Terminate the kss process: DISPLAY=:0.0 dcop kdesktop KScreensaverIface quit

* Wait about 10 seconds.
* Verify three Trinity screen saver processes are running: ps ax | grep kss

* Toggle to the Trinity desktop (Ctrl-Alt-F7). Verify three screen saver banners.

I use the dcop command in some wrapper scripts in my HTPC. I discovered this bug a several months ago after updating my HTPC from 3.5.10 to R14 (I built the HTPC a few years ago, hence having 3.5.10 installed). After updating to R14, I noticed the screen saver was running when that had never happened previously. Eventually I narrowed the problem to the dcop command in my script wrappers. I then tested the dcop command in a 3.5.13.0 VM. The dcop command works fine in 3.5.13.

There has been a lot of work with the lock mechanism. Possibly something in that work affects the dcop command?

I forgot to add, after toggling back to Trinity and verifying three banners, stop the screen saver in a normal manner with a keyboard press or mouse movement.

Verify two kss processes are still running.

Thank you for the detailed explanation.  This should be fixed in GIT hash db67e0b.

Thanks for reporting!

Looks good here. Thanks!