.xsession-errors file grows up to 50GB
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.
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 -- Blade hails you... An angel face smiles to me Under a headline of tragedy --Nightwish
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.
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? -- Blade hails you... None of you understand And it doesn't matter To a broken marionette like me --Nightwish
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
Julián, On Friday 20 October 2006 12:00, Julián Rodríguez Bajo wrote:
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.
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. Randall Schulz
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. -- Blade hails you... I am the dark side of you --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.
On 21.10.2006 00:49, Julián Rodríguez Bajo wrote:
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.
I don't know for sure, but I think there is no easy way. Of course you could always search through the sources:) -- Blade hails you... It is the journey that matters, the distant wanderer --Nightwish
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
Boyan, Julian On Friday 20 October 2006 14:25, Boyan Tabakov wrote:
...
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.
Indeed. Everything you wrote here and in the preceding post is correct, though I believe all POSIX-compatible file systems support writing at arbitrary locations, either within or beyond the current end-of-file. Whether or not the file "holes," as they are indeed called, are backed by allocated disk blocks or have their zero-fill content supplied by the file system code, I'm not sure. In the old days, when there was just "the" Unix file system, it was definitely the case that holes were not allocated disk blocks. It's also true that not all programs are smart about recreating holes when the copy such files. Some do, some don't, so even if the file is not now taking up as many blocks as its logical size suggests, it may occupy that many when, say, a backup is performed. YMMV, as they say... Randall Schuzl
participants (3)
-
Boyan Tabakov -
Julián Rodríguez Bajo -
Randall R Schulz