[kde-linux] "The name org.kde.kded was not provided by any .service files"

[Kevin Krammer]

On Sunday, 2013-08-04, James Tyrer wrote:

> However, not to go over the same thing again, but I do have this
> puzzling error message:
> 
> rekonq(13587)/kdecore (K*TimeZone*): KSystemTimeZones: ktimezoned
> initialize() D-Bus call failed:  "The name org.kde.kded was not provided
> by any .service files"
> 
> clearly indicating a missing: "org.kde.kded.services" file.

No, this is a misleading false positive. The problem is a call to an 
unregistered name, resulting in a fallback like situation.

> Since you understand D-Bus better than I do, perhaps you can explain
> what you think happened that resulted in the above error message.  From
> your previous explanation, it is my understanding that some KDE code
> used D-Bus to send a message to Kded which D-Bus didn't find so it tried
> to: initialize() Kded but didn't find the Service file to do so and the
> error message was issued.

initialize is probably the method that the sender would like to call or it is 
the method were the D-Bus call originates from.
The sender program most likely handles the case of the failed call anyhow, so 
it just sends the messsage without checking for the presence of the name 
first.

Unfortunately this triggers D-Bus code which attempts activation, something 
that is neither the intent of the caller nor supported by the receiver.
The reported error is the result of some automagic kicking in that is not 
applicable to the situation at hand.

> Has the code base become so large and complex that we really don't
> understand how it works in _all_cases_?  I emphasize the _all_cases_
> because it is important to consider all possible cases, not just the
> normal ones, when designing code.  It appears obvious that I (as well as
> some other users I found with a Google search) somehow generated a
> non-nominal case where the code would not work without this file.  To
> say that it is non-nominal cases that cause bugs to appear is to merely
> restate the obvious.

We unfortunately don't have enough information to conclude whether the code 
works or not. Since there seems to be no obvious error reported for the actual 
call failure I would lean towards "works".

The seen error message is a result of some D-Bus code being overly helpful, 
not necessarily an indication of an unexpected situation on the side of the 
actual client code.

> Since I can not reproduce the problem, I can only suggest that KDELibs
> should install the file based on the established fact that it is
> possible for code to call the file in some circumstances and there
> appears to be no easy way for a user to fix whatever problem that caused
> a call to the file.

Adding a second activation path is not something one should do lightly. There 
could be unwanted side effects, e.g. kded then running in a different 
environment (being a chilld of D-Bus daemon instead of kdeinit), etc.

Assuming you are not seeing any actual error from the application itself I 
would assume that it handled the call failure as one of the possible 
consequences of a remote method call.

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-linux/attachments/20130804/58bcbd3c/attachment.sig>