Bug 109715

Summary:	Can't clear stored passwords, KDE on demand helpers don't exit.
Product:	[Websites] docs.kde.org	Reporter:	Tom <twl8n>
Component:	general	Assignee:	Jes Hall <jhall>
Status:	RESOLVED FIXED
Severity:	normal	CC:	tchollingsworth
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	Fedora RPMs
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Tom 2005-07-27 15:42:46 UTC

Version:           3.3.1-4.3.FC3 Red Hat (using KDE KDE 3.3.1)
Installed from:    Fedora RPMs
OS:                Linux

The KDE FAQ is wrong. kdesu -s does not clear stored .htaccess style passwords.

The "on demand" KDE services don't exit when there are no longer any running instances of KDE applications. 

There is no way to kill off the KDE "on demand" services, short of using the kill command or logging out.

Comment 1 Stephan Binner 2005-07-29 11:28:01 UTC

"kdesu -s does not clear stored .htaccess style passwords."

Either the faq is wrong or you misunderstood what kdesu is for.

Comment 2 Jes Hall 2005-07-29 11:53:24 UTC

What parts of which version of wihch faq are you talking about here? Grepping for 'kdesu' through the sources of the current version of the main KDE faq comes up with absolutely nothing, as does grepping for 'demand' 

more information is required please =)

Comment 3 Tom 2005-07-29 15:02:09 UTC

Sorry about that. The "kdesu -s" reference is in the Konqueror FAQ. 

http://konqueror.kde.org/faq/

BTW, there's no man page for kdesu or kdesud.

Thanks.

Comment 4 Jes Hall 2005-07-29 15:14:29 UTC

Ok then - the konqueror faq is in the process of being merged into the main faq and then removed :) The question about kdesu wont be in the merged document, and neither will any other incorrect or out of date questions.

Comment 5 Marek Laane 2007-08-01 23:49:17 UTC

Well, there seems to be no more such phrase in Konqueror handbook and there is kdesu handbook - is the bug fixed?

Comment 6 Marek Laane 2007-08-31 23:21:16 UTC

Ping?

Comment 7 T.C. Hollingsworth 2011-12-08 11:03:37 UTC

This seems to have been resolved in the intervening years.  If there is still something wrong, please let us know.