Bug #381447 “kded can't find “kded/networkstatus.desktop"" : Bugs : kde4libs package : Ubuntu

Revision history for this message

Harald Sitter (apachelogger) wrote on 2009-07-08:

#1

So don't start it from a console?
Or don't turn on debugging?

Unless kded eats all your CPU because it can't find that file, this is not really a bug IMHO.

Changed in kde4libs (Ubuntu):
status:	New → Invalid

Revision history for this message

Tomas Pospisek (tpo-deb) wrote on 2009-07-08:

#2

Harald Sitter wrote 1 hour ago
>
> So don't start it from a console?

1. I did not start it from the console. Some other kde program that I started from the console apparently needed kded.
2. Even if I wanted, I couldn't start kded in any other way, since as far as I can see there is no entry anywhere in any menu. Or can you find one?
3. There is no policy I know of that says that problems when running a kde application from the console should be ignored. (The "Clicki-bunti don't touch the keyboard, you are in Windows land now, where you only need and only are allowed to use one finger of those ten on your hand" policy). Or is there?

> Or don't turn on debugging?

I didn't turn debugging on. I wouldn't even know how if I wanted.

> Unless kded eats all your CPU because it can't find that file, this is not really a bug IMHO.

So what is this behaveour then? A feature? Not really or is it? Thus I'm changing the Status from "Invalid" to "New".

This behaveour fills the console with garbage while one is trying to do some useful work, you know, like editing a file in vim (dauntingly inside a console, wheee!) for example.

But check out that kded's dump. It doesn't say that it is in debug mode. It says that it can't find some file that it _needs_. So either that file should be included or it shouldn't be needed. And if it's not needed than kded should *warn* at most *1* time about the fact and not whine uncessantly about it filling the console with noise.

*t

Changed in kde4libs (Ubuntu):
status:	Invalid → New

Revision history for this message

Tomas Pospisek (tpo-deb) wrote on 2009-07-08:

#3

Check also #324995 for a different example from the wild (second hit on Google for "kded KServiceFactory::findServiceByDesktopPath").

Revision history for this message

Tomas Pospisek (tpo-deb) wrote on 2009-07-08:

#4

as google seems to suggest, that kind of console spamming seems to be quite a common phenomenon, affecting no small number of people...

Revision history for this message

Tomas Pospisek (tpo-deb) wrote on 2009-07-08:

#5

kded's message is also displayed very prominently in this juicy blogpost - http://marc.waeckerlin.org/computer/blog/get_rid_of_xsession-error_that_s_filling_up_the_home_directory

Revision history for this message

Jonathan Thomas (echidnaman) wrote on 2009-07-24:

#6

Could you check to see if the file is actually there? (Should be at /usr/share/kde4/services/kded/networkstatus.desktop)

Changed in kde4libs (Ubuntu):
importance:	Undecided → Low
status:	New → Incomplete

Revision history for this message

Tomas Pospisek (tpo-deb) wrote on 2009-07-24:

#7

On Fri, 24 Jul 2009, Jonathan Thomas wrote:

> Could you check to see if the file is actually there? (Should be at
> /usr/share/kde4/services/kded/networkstatus.desktop)

It's not there:

$ ls -l /usr/share/kde4/services/kded/networkstatus.desktop
ls: cannot access /usr/share/kde4/services/kded/networkstatus.desktop: No such file or directory

Greets,
*t

Changed in kde4libs (Ubuntu):
status:	Incomplete → New

Revision history for this message

Jonathan Thomas (echidnaman) wrote on 2009-07-24:

#8

Is kdebsae-workspace-bin installed? Are you running in a KDE environment? (I suppose I should have grouped that with my first question)

Changed in kde4libs (Ubuntu):
status:	New → Incomplete

Revision history for this message

Tomas Pospisek (tpo-deb) wrote on 2009-07-25:

#9

On Fri, 24 Jul 2009, Jonathan Thomas wrote:

> Is kdebsae-workspace-bin installed? Are you running in a KDE
> environment? (I suppose I should have grouped that with my first
> question)

No, it's not installed and I run from the default Ubuntu desktop install, which is Gnome. I do only install selected KDE applications (korganizer, ksnapshot, kwallet, klipper, et al.).

$ dpkg -s kdebase-workspace-bin
Package `kdebase-workspace-bin' is not installed and no info is available.

*t

Changed in kde4libs (Ubuntu):
status:	Incomplete → New

Revision history for this message

Jonathan Thomas (echidnaman) wrote on 2009-07-25:

#10

Hmm, I wonder what is trying to use the network management module... Well, kded obviously, but what's trying to start that kded service? (Rhetoric question, don't feel obligated to answer ;-)

Revision history for this message

Harald Sitter (apachelogger) wrote on 2009-08-08:

#11

Well, then lets take a look at it form a non-clicki-bunti POV.

kded should be started independently, since it is much more verbose than applications, for a very good reason as I tend to believe. Also kded is an own application anyway. Only for user convenience KDE applications would startup kded if it is not running already, so that clicki-bunti-users do not have to worry about it.
Should one considering this very reasonable point and still not start kded independently and let an app start kded, one should at least make sure all output gets passed to /dev/null.

To a more useful analysis of the "problem"...

_Any_, I repeat, _any_ KDE app can use the troublesome module. As a matter of fact most will do via the http kioslave (that to my knowledge tries to use the networkstatus module to access link information and thus timeout immediately if no connection is available at all), also any application that would want to have status information about the network link status would either implement access on networkstatus via a kioslave or do it in the app directly.

Meaning that the following apps will for sure use networkstatus:
* KDEPIM
* Amarok (last.fm, lyrics and whatnot)
* KTorrent
* Konqueror
* Kopete
* most Plasma applets
...

The query frequency is set by the app itself, so the more often it tries to access the status, the more often will kded report that it is not available. Also, the more apps are querying the more output you get, due to increased query volume.

All those apps are perfectly capable of living without the module (which is mostly the point of kded modules that are shipped independent from the app), still it is desirable to have the module installed, otherwise the apps will not be able to treat network loss (properly). Thus it makes sense to have this message displayed

So, to get back to your question, yes I consider this a feature, so should you, since a smoothly running system is in the interest of every non-clicki-bunti user.

What we can do about it?
* We can increase the query frequency of each app (i.e. maintain 3 billion patches)
* We can make each package depend on workspace-bin (thus forcing the better part of the KDE desktop upon every user and devalue the point of kded modules)
* We can make these warnings disappear all along and thus prevent users that actually try to find out why the apps are unable to track network status of diagnosing the problem
* We can make kded track it's own verbosity (that of course requires kded to store information when a uniquely identified message was sent, and define a maximum frequency to that, in return we get more mem usage and still didn't get rid of the warnings)

What's it gonna be?

Well, then lets take a look at it form a non-clicki-bunti POV.

kded should be started independently, since it is much more verbose than applications, for a very good reason as I tend to believe. Also kded is an own application anyway. Only for user convenience KDE applications would startup kded if it is not running already, so that clicki-bunti-users do not have to worry about it.
Should one considering this very reasonable point and still not start kded independently and let an app start kded, one should at least  make sure all output gets passed to /dev/null.

To a more useful analysis of the "problem"...

_Any_, I repeat, _any_ KDE app can use the troublesome module. As a matter of fact most will do via the http kioslave (that to my knowledge tries to use the networkstatus module to access link information and thus timeout immediately if no connection is available at all), also any application that would want to have status information about the network link status would either implement access on networkstatus via a kioslave or do it in the app directly.

Meaning that the following apps will for sure use networkstatus:
* KDEPIM
* Amarok (last.fm, lyrics and whatnot)
* KTorrent
* Konqueror
* Kopete
* most Plasma applets
...

The query frequency is set by the app itself, so the more often it tries to access the status, the more often will kded report that it is not available. Also, the more apps are querying the more output you get, due to increased query volume.

All those apps are perfectly capable of living without the module (which is mostly the point of kded modules that are shipped independent from the app), still it is desirable to have the module installed, otherwise the apps will not be able to treat network loss (properly). Thus it makes sense to have this message displayed

So, to get back to your question, yes I consider this a feature, so should you, since a smoothly running system is in the interest of every non-clicki-bunti user.

What we can do about it?
* We can increase the query frequency of each app (i.e. maintain 3 billion patches)
* We can make each package depend on workspace-bin (thus forcing the better part of the KDE desktop upon every user and devalue the point of kded modules)
* We can make these warnings disappear all along and thus prevent users that actually try to find out why the apps are unable to track network status of diagnosing the problem
* We can make kded track it's own verbosity (that of course requires kded to store information when a uniquely identified message was sent, and define a maximum frequency to that, in return we get more mem usage and still didn't get rid of the warnings)

What's it gonna be?

Changed in kde4libs (Ubuntu):
status:	New → Incomplete

Revision history for this message

Tomas Pospisek (tpo-deb) wrote on 2009-09-01:

#12

Download full text (4.7 KiB)

Hello Harald, KDE maintainers and developpers,

first thanks for the factual reply.

On Sat, 8 Aug 2009, Harald Sitter wrote:

> Well, then lets take a look at it form a non-clicki-bunti POV.
>
> kded should be started independently, since it is much more verbose
> than applications, for a very good reason as I tend to believe. Also
> kded is an own application anyway. Only for user convenience KDE
> applications would startup kded if it is not running already, so that
> clicki-bunti-users do not have to worry about it.

OK

> Should one considering this very reasonable point and still not start
> kded independently and let an app start kded, one should at least make
> sure all output gets passed to /dev/null.

However that assumes that users should somehow know that this is
necessary-

> To a more useful analysis of the "problem"...
>
> _Any_, I repeat, _any_ KDE app can use the troublesome module. As a
> matter of fact most will do via the http kioslave (that to my knowledge
> tries to use the networkstatus module to access link information and
> thus timeout immediately if no connection is available at all), also any
> application that would want to have status information about the network
> link status would either implement access on networkstatus via a
> kioslave or do it in the app directly.
>
> Meaning that the following apps will for sure use networkstatus:
> * KDEPIM
> * Amarok (last.fm, lyrics and whatnot)
> * KTorrent
> * Konqueror
> * Kopete
> * most Plasma applets
> ...
>
> The query frequency is set by the app itself, so the more often it tries
> to access the status, the more often will kded report that it is not
> available. Also, the more apps are querying the more output you get, due
> to increased query volume.
>
> All those apps are perfectly capable of living without the module (which
> is mostly the point of kded modules that are shipped independent from
> the app), still it is desirable to have the module installed, otherwise
> the apps will not be able to treat network loss (properly). Thus it
> makes sense to have this message displayed
>
> So, to get back to your question, yes I consider this a feature, so
> should you, since a smoothly running system is in the interest of every
> non-clicki-bunti user.
>
> What we can do about it?
> * We can increase the query frequency of each app (i.e. maintain 3
> billion patches)
> * We can make each package depend on workspace-bin (thus forcing the
> better part of the KDE desktop upon every user and devalue the point
> of kded modules)
> * We can make these warnings disappear all along and thus prevent users
> that actually try to find out why the apps are unable to track network
> status of diagnosing the problem

Or the warnings could go to some log, such as ~/.xsession-errors or
~/.kde/tmp-$user-$host/kded.log

> * We can make kded track it's own verbosity (that of course requires
> kded to store information when a uniquely identified message was sent,
> and define a maximum frequency to that, in return we get more mem
> usage and still didn't get rid of the warnings)

I lack the knowledge the workings of kdeapp<->kded<->ksycoca<->modules
and so am wonder...

Hello Harald, KDE maintainers and developpers,

first thanks for the factual reply.

On Sat, 8 Aug 2009, Harald Sitter wrote:

> Well, then lets take a look at it form a non-clicki-bunti POV.
>
> kded should be started independently, since it is much more verbose
> than applications, for a very good reason as I tend to believe. Also
> kded is an own application anyway. Only for user convenience KDE
> applications would startup kded if it is not running already, so that
> clicki-bunti-users do not have to worry about it.

OK

> Should one considering this very reasonable point and still not start
> kded independently and let an app start kded, one should at least  make
> sure all output gets passed to /dev/null.

However that assumes that users should somehow know that this is
necessary-

> To a more useful analysis of the "problem"...
>
> _Any_, I repeat, _any_ KDE app can use the troublesome module. As a
> matter of fact most will do via the http kioslave (that to my knowledge
> tries to use the networkstatus module to access link information and
> thus timeout immediately if no connection is available at all), also any
> application that would want to have status information about the network
> link status would either implement access on networkstatus via a
> kioslave or do it in the app directly.
>
> Meaning that the following apps will for sure use networkstatus:
> * KDEPIM
> * Amarok (last.fm, lyrics and whatnot)
> * KTorrent
> * Konqueror
> * Kopete
> * most Plasma applets
> ...
>
> The query frequency is set by the app itself, so the more often it tries
> to access the status, the more often will kded report that it is not
> available. Also, the more apps are querying the more output you get, due
> to increased query volume.
>
> All those apps are perfectly capable of living without the module (which
> is mostly the point of kded modules that are shipped independent from
> the app), still it is desirable to have the module installed, otherwise
> the apps will not be able to treat network loss (properly). Thus it
> makes sense to have this message displayed
>
> So, to get back to your question, yes I consider this a feature, so
> should you, since a smoothly running system is in the interest of every
> non-clicki-bunti user.
>
> What we can do about it?
> * We can increase the query frequency of each app (i.e. maintain 3
>   billion patches)
> * We can make each package depend on workspace-bin (thus forcing the
>   better part of the KDE desktop upon every user and devalue the point
>   of kded modules)
> * We can make these warnings disappear all along and thus prevent users
>   that actually try to find out why the apps are unable to track network
>   status of diagnosing the problem

Or the warnings could go to some log, such as ~/.xsession-errors or
~/.kde/tmp-$user-$host/kded.log

> * We can make kded track it's own verbosity (that of course requires
>   kded to store information when a uniquely identified message was sent,
>   and define a maximum frequency to that, in return we get more mem
>   usage and still didn't get rid of the warnings)

I lack the knowledge the workings of kdeapp<->kded<->ksycoca<->modules
and so am wondering whether the situation is really that dramatic that a
resolution would require _significant_ storage. I.e. ksycoca is designed to
hold service and configuration information in the first place. So knowing
that some module has not been loaded - here: because it's not there - is
part of the configuration information. Whoever is responsible for loading
the module can warn in the log that it was not found. Next time the module
is needed the code required for loading the module can check the relevant flag
"i_have_allready_reported_the_status_of_the_module", return a negative
answer to the requester, not log anything else and be done with it. That would
not inflate in any noticeable way the storage demands of KDE?

> What's it gonna be?

With my limited knowledge I'd suggest to
a) have a log for non-critical messages and to only show critical problems
   to the user by default
b) remember whether access to some module has allready been tried without
   success and not re-report that fact.

I realize that my initial reply wasn't (once again) emotionaly neutral (as in
"sachlich") so thanks to you for going ahead in a constructive way all the
same. I guess you agree that all apps should be fun and/or convenient to
work with and avoid annoying the user uselessly (here: the user only needs
to know once, that something is not OK and it's arguable whether the problem
at hand is as important as to necessitate writing to stderr (?)), if it's reasonably
avoidable. My impression is that a technical solution should be possible
without any exagerated measures?

Thanks,
*t

Changed in kde4libs (Ubuntu):
status:	Incomplete → New

Revision history for this message

Harald Sitter (apachelogger) wrote on 2009-11-06:

#13

Fix committed and to be appearing in Kubuntu 10.04 (r1018439)

Changed in kde4libs (Ubuntu):
status:	New → Fix Committed

Revision history for this message

Jonathan Thomas (echidnaman) wrote on 2009-12-07:

#14

Fix released to the development version of Kubuntu 10.04.

Changed in kde4libs (Ubuntu):
status:	Fix Committed → Fix Released

Ubuntu
kde4libs package

kded can't find "kded/networkstatus.desktop"

Bug Description

Other bug subscribers

Remote bug watches

Ubuntukde4libs package

kded can't find "kded/networkstatus.desktop"

Bug Description

Other bug subscribers

Remote bug watches

Ubuntu
kde4libs package