For some time, I have been having a problem with the drive that holds my /home and I finally figured it out. Now I have to figure out whose bug it is.

Basically, the problem was that over the course of a KDE login session (which would usually last for weeks or months) the hard drive that had /home on it would fill up completely. The system isKDE 3.3.2, Mandriva 10.1-10.2 - meaning upgraded piecemeal from 10.1.

Some time back I figured out that the problem was with .xsession-errors, which was in my home directory. I run Kplayer quite a bit, and it is chatty. It hasn't been upgraded for over a year now and the version I have evidently has a lot of debug stuff turned on, which it writes to .xsession-errors.

Well, when I first figured this out, the solution seemed simple and it worked OK. I would close Kplayer, then delete .xsession-errors. This worked fine.

Time passed, many package upgrades...

Then the problem started, with the drive filling up. Well, I figured out that .xsession-errors, even though deleted, did not go away and continued to grow. Some work with lsof and grep showed that kdeinit was holding .xsession-errors open all the time, so I could not delete it. Seems that gconfd has it open a lot too, even when not writing anything.

Workaround to this point; as root, I have replaced .xsession-errors with a link to /dev/null. I don't know if this will survive a reboot; if it doesn't then I'll put some code into an initscript to make it happen.

But, whose bug is this?

Kplayer should have debug messages turned off - bug.

Kdeinit and gconfd should not hold .xsession-errors open unless writing to it. - bug.

Beyond that, the file system is ext3, and this filesystem should either (a) not allow the deletion of an open file; or (b) should really delete it and invalidate the file handles. So whose bug is this? Kernel developers? File system developers? Both?

Opinions? Suggestions?

Yeah, that will persist through a reboot.

Kplayer is a front-end to mplayer. Have a look at mplayer's config for a way to surpress logging.

Are you sure? Perhaps it is just writing a burst of messages

I would not be so quick to call things bugs. How do you know that the process isn't immediately opening the file for writing after you delete it.

All this said, I would _read_ the messages being written rather than chucking them out, and figure out why they are being written in the first place.

If it is, as you think, just plain and simple debug 'chattiness' then certainly there is a way to turn it off. Investigate this...

there are lots of different kinds of bugs.
certainly this is a bug by virtue of the fact that the error logging is destroying your session with filing up the disk (not the expected behaviour)
many of us have seen disks fill up with this bug.

.xsession-errors is a file where xdm/gdm/kdm redirect stdin/stdout away from themselves and to a file.

when you don't use a display manager this stuff is on the controlling tty without being logged. unfortunately i think these errors would be lost without the file in an xsession(display manager session) hence the file.

mplayer is rather notorious for logging all kinds of crap to stderr.

My opinion i think this is from /etc/X11/Xsession script that is part of X
so it is a bug in X and that is where it should be fixed.
it has been there for a very long time.

I don't mean to degrade the significance of this problem, but how long does one need to keep their X session open in order for the .xsession-error file to grow so big? It sure depends upon which applications to run, but for instance, I've had my KDE session open since this morning (i.e. over 10 hours), using all sorts of apps such as Kaffeine, Firefox, Kontact, Kopete, Konsole, The GIMP, etc., etc. The size of my .xsession-errors is little over 22KB.

xsession just opens the file and writes to it if it can
it doesn't create it or ever delete it so the file is cumulative.

Messages are all prefixed "kplayer". There might be a compile option to supress these things, but what they are - what they say - look to me like programmer-written "whatthehellisgoingon" type of debug messages. Since kplayer seems to be stuck at 0.5.3, it could be that these do NOT have a nice way to be turned off. I haven't looked.



Oh, I am quite sure. No error messages forever, but can't delete file. Or, more properly, it deletes but not really.



In that case, I would expect it to recreate the file and start from zero.

Three gigs of messages is a tad tedious to read. Particularly when almost all of them tell me nothing but the internal state of kplayer.

Actually, this is the problem with symlinking the file. If any real problems come rattling through, I won't know it.

Keeping in mind that I work at my system about 8 to 10 hours/day and during that time I almost always have kplayer running either playing local files or streaming off the internet, and it takes about 4 weeks to suck up about 3 gigs.

After that, I have to shut down clear to runlevel one then come back up. Considering that I run VMWare 100% of the time with one or two Win2K installations up, running, and working, and I ordinarily have SSH sessions up and running to a number of different computers around the world, what you see is that I have to go through a bit of an exercise to clean out that file.

Does it mean that the .xsession-error file doesn't get cleared every time you log out of your X session?

it might help to compile kplayer with --disable-debug

and yes the file is held open as it is called with the exec command from x

Not so long as X is running. Seems that kdeinit keeps running even in runlevel 3, which is why I have to go all the way to runlevel 1.

And, actually, I never log out of my X session except when required to do maintenance. Or when my drive is close to full.