El Viernes, 20 de Octubre de 2006 20:49, Boyan Tabakov escribió:

On 20.10.2006 21:43, Julián Rodríguez Bajo wrote:

...

Hi friends.

I have noticed that file .xsession-errors in my home directory grows and grows out of control. Since my KDE sessions last for many days or even weeks, I am forced to restart my machine from time to time. I have tried running kdebugdialog and disable all items, but it has no effect.

Regards.

Hi, If you don't care about the contents of that log, you can simply flush it from time to time - no need to restart. Just type:

$ cat /dev/null > ~/.xsession-errors

Thanks for your reply Boyan, but after exec that command, next time any process writes to the file the file size goes back to the previous file size.

El Viernes, 20 de Octubre de 2006 21:18, Boyan Tabakov escribió:

On 20.10.2006 22:00, Julián Rodríguez Bajo wrote:

...

Thanks for your reply Boyan, but after exec that command, next time any process writes to the file the file size goes back to the previous file size.

Now this is strange. Same here. I use this technique to flush log files and for what I know about file systems it is the right way to do it. I tried this again with /var/log/messages - a file that gets written into really often. It worked just file - the file was flushed and not restored after subsequent write. However, this is not the case with .xsession-errors. Part of the file seems binary data, but I don't know why it is not behaving like I think it should. It is a regular file after all. Anybody, any ideas?

lsof reports that /var/log/messages is opened just once by process syslog/syslog-ng, but .xsession-errors is opened by a lot of KDE processes (kio_*, start_kde, kdeinit, dcopserver...) Also, as you say, the begining of the file are just a lot of 0x00 (32945 0x00 bytes on my system right now) followed by normal text messages.

On 20.10.2006 23:40, Julián Rodríguez Bajo wrote:

lsof reports that /var/log/messages is opened just once by process syslog/syslog-ng, but .xsession-errors is opened by a lot of KDE processes (kio_*, start_kde, kdeinit, dcopserver...)

Also, as you say, the begining of the file are just a lot of 0x00 (32945 0x00 bytes on my system right now) followed by normal text messages.

Indeed. Did some experimenting with the help of good old stdio.h The 0x00s in the begining of the file are actually the hole in a "file with holes" that can be created on some file systems. These are created when a programme writes to a position in the file outside its current size. Now flushing an opened file with cat /dev/null > file works excellent on files opened in append mode (fopen("file", "a")), but result in file holes when the file is opened in write mode. What troubles me here is why .xsession-errors is not opened in append mode? -- Blade hails you... Deep dark is His Majesty's kingdom A portent of tomorrow's world There shall the liquid give Him power The red-eyed unborn lord --Nightwish

El Viernes, 20 de Octubre de 2006 23:25, Boyan Tabakov escribió:

On 21.10.2006 00:05, Randall R Schulz wrote:

...

This indicates that at least one of the process(es) writing to that file has not opened it in O_APPEND mode (or switched to append mode after opening it). This is surprising, since it's a bit of a rookie programming mistake. Sadly, it only takes one such erroneously written program to mess things up in this way, since the programs that do properly write with O_APPEND will, as the name suggest, always have their contributions to the file placed at the very end, wherever that happens to be at the moment their write request is received by the kernel. Furthermore, the kernel guarantees that O_APPEND-mode writes will not interfere with each other. In contrast, programs that seek to the end and then start writing may well overwrite the data of concurrent writers.

Nice:) Just clicked 'send' and KMail fetched your answer too:) Anyway... so I was right... it is a broken open call.

@Julian - you shouldn't bother with the reported file size, when you flush it with cat /dev/null > .xsession-errors since the holes of the files are not actually written to disk (at least not the holes bigger than one block). You won't waste any space.

Thanks Randal, and thanks Boyan. Is there any way to know which process opens the file in a wrong way? I have tried with lsof and fuser, but the information reported does not seem to show open mode. Also, df and du shows that .xsession-errors file size is not available/used Regards.

Julian, On Friday 20 October 2006 15:13, Boyan Tabakov wrote:

On 21.10.2006 00:49, Julián Rodríguez Bajo wrote:

...

Thanks Randall, and thanks Boyan. Is there any way to know which process opens the file in a wrong way? I have tried with lsof and fuser, but the information reported does not seem to show open mode.

I don't know for sure, but I think there is no easy way. Of course you could always search through the sources:)

Were we not on Linux, it would be possible using the "+fg" option: -==--==--==--==--==--==--==--==--==--==--==--==--==--==--==- "The listing of information from kernel file structures, requested with the +f [cfgGn] option form, is normally inhibited, and is not available for some dialects - e.g., /proc-based Linux. When the prefix to f is a plus sign (`+'), these characters request file structure information: c file structure use count f file structure address g file flag abbreviations G file flags in hexadecimal n file structure node address ... "FILE-FLAG when g or G has been specified to +f, this field contains the contents of the f_flag[s] member of the kernel file structure and the kernel's per-process open file flags (if available); `G' causes them to be displayed in hexadecimal; `g', as short-hand names; ...: AIO asynchronous I/O (e.g., FAIO) AP append ... [ and many more ] " -==--==--==--==--==--==--==--==--==--==--==--==--==--==--==- Note especially: "... is not available for some dialects - e.g., /proc-based Linux." Randall Schulz