Bug 107033 - QFile::open: No file name specified xsession-errors
Summary: QFile::open: No file name specified xsession-errors
Status: RESOLVED DUPLICATE of bug 108629
Alias: None
Product: kdelibs
Classification: Frameworks and Libraries
Component: kded (show other bugs)
Version: 3.4.1
Platform: Debian testing Linux
: NOR normal
Target Milestone: ---
Assignee: Unassigned bugs mailing-list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-06-08 14:31 UTC by arne anka
Modified: 2005-07-06 14:05 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description arne anka 2005-06-08 14:31:01 UTC
Version:           3.4.1 (using KDE KDE 3.4.1)
Installed from:    Debian testing/unstable Packages

my .xsession-errors is full of lines saying "QFile::open: No file name specified" and ca every 1/20sec a new line is appended. it starts litterally at login in kdm so some daemon may trigger this. practically it means may harddisk is always busy writting useless data.
Comment 1 Stephan Kulow 2005-06-08 17:25:36 UTC
well, works here. It can be anything - including things only existing on your system. you need to find out who does that, e.g. by stracing every k process.
Comment 2 arne anka 2005-06-10 08:50:31 UTC
why is a mail to the bugtracker not appended?

it's the kded (strace'd it) -- killing stops logging immediatelly, but prevents kopete from connecting and konqueror from accepting cookies. maybe there are more sideeffects so killing is not the best way to get rid of. what file looks kded for (and why does it not latch on after the first time accessed tah there's no file???)?
Comment 3 arne anka 2005-06-15 09:30:48 UTC
could somebody please assign this bug to kded?

some additional informations:
- presuming the message may be caused by a missing kdedrc i created one and placed it in either $HOME/.kde/share/config and /etc/kde3/

[General]
PollInterval=12000
NFSPollInterval=12000
HostnamePollInterval=12000
CheckSycoca=true
CheckUpdates=true
CheckHostname=true

but the error still occurs
- killing kded and restarting stops writing of the message above but kded still accesses the disk about 2 times per second -- killing kded stops this activity so it's undoubtely caused by kded. even worse -- after creating the kdedrc i expected the interval to be like 12000 not 500 (the default obviously!) as it seems. did the format of the kdedrc change? at least the location is the one kded looks for (strace says so).
Comment 4 Stephan Kulow 2005-06-15 15:50:54 UTC
the problem is that kded is just a daemon that has several modules. Don't kill kded but unload module by module over dcop kded
Comment 5 arne anka 2005-06-15 18:35:12 UTC
could you explain this a bit more? how do know which modules are in use and how do i unload a module exactly?
Comment 6 Waldo Bastian 2005-06-15 21:37:34 UTC
You can see all modules loaded by KDED with the following command:
 dcop kded kded loadedModules

You can unload a module with:
 dcop kded kded unloadModule <module name>
Comment 7 arne anka 2005-06-16 10:41:47 UTC
thanks. removing the mediamanager-module stops the pulsating disk access (maybe the QFile... line, too. but kded crashed and after restart the line is always gone, see comment #3).
are there informations about the modules (e g what does mediamanger do, what kmilod? how to configure, ho to disable loading?)?
Comment 8 arne anka 2005-06-21 16:08:53 UTC
the QFile ... line is not caused by mediamanger. so atm i always after kde is up and running have to kill kded and restart it (to get rid of the QFile line) and after that to do a "dcop kded kded unloadModule mediamanager" to get rid of the disk access.
Comment 9 mlord 2005-06-28 18:31:41 UTC
Looks like perhaps udev is pulling out a device node from under kded's feet.

Maybe..
Comment 10 arne anka 2005-06-29 08:55:33 UTC
i'm not using udev.
Comment 11 Jörg Walter 2005-06-29 10:51:00 UTC
I have this problem as well. Preliminary results: it happens in the third thread. Unloading module "systemdirnotify" stops it. But it's actually the laptop battery monitor that triggers it: after restarting "systemdirnotify", no messages appear. Only after restarting the laptop battery monitor does it happen. (Note that I stopped the battery monitor before unloading systemdirnotify)
Comment 12 Jörg Walter 2005-06-29 11:04:08 UTC
Okay, some more results: Maybe the laptop battery monitor has nothing to do with it. I don't get these lines anymore, even with the monitor running. The only thing I changed was that I corrected one system notification sound that still pointed to a nonexisting file. It was konsole's beep, so I very likely triggered it all the time while experimenting with strace, the laptop daemon and all that.
Comment 13 Waldo Bastian 2005-07-06 14:05:48 UTC

*** This bug has been marked as a duplicate of 108629 ***