GNU/Linux, Open Source, Cloud Computing, DevOps and more...

How to prevent the .xsession-errors file from growing to a huge size

17 comments

Xorg iconThe .xsession-errors file is where the X Window system logs all errors that occur within the Linux graphical environment. All desktop environments, whether Gnome, KDE, Cinnamon, XFCE, LXDE, etc., and all lighter window managers like FVWM, IceWM or Window Maker make use of the X Window system. Therefore any graphical application running on your computer can cause that error messages are written to the .xsession-errors file, reason why it can grow wildly until reaching very big sizes of tens of GB or even hundreds if your disk capacity allows it.

Just as this problem affects different desktop environments and window managers based on X Window (that is, all of them), all Linux distributions, whether Ubuntu, Fedora, Debian or ArchLinux can also be affected.

Although there is a control mechanism in the /etc/X11/Xsession file that causes the file to be emptied each time the graphical environment starts up if it exceeds a certain size, if you are one of those who, like me, normally suspend the computer instead of powering it off when the working day ends, it may be that you don’t restart your computer for weeks or even months, which means that the .xsession-errors file will never be truncated and can reach a gigantic size. And although you do frequently restart the system, it also happens that some applications, whether due to some type of failure/error or because they misuse the error log, start to send uncontrolled thousands and thousands of messages to .xsession-errors.

The .xsession-errors file is usually located in your home directory and the only problem it should cause is that your personal folder is full. But if you have not partitioned your disk properly and only have one partition for the entire root (/) file system, the fast growth of .xsession-errors can cause your computer to stop working and crash.

Further reading:
  The importance of properly partitioning a disk in Linux

Empty the .xsession-errors file

If it already happened that you ran out of disk space and using the du -k /home | sort -n | tail -5 command you were able to determine that the .xsession-errors file is the one that takes up more space, the first step to fix the problem is to empty it completely:

$ >~/.xsession-errors

Prevent .xsession-errors from growing out of control

Once the space is freed, you will want this situation not to be repeated again in the future. To achieve this it is best to try to find the origin of the problem, ie, to know which process is writing uncontrolled to the error log and why. For this you can use the fatrace command as indicated in this other post: Fatrace command: how to know in real time which processes are writing to a file.

Another interesting measure to adopt is to add a task to your crontab to periodically check the size of .xsession-errors file. If it exceeds a certain threshold, empty or truncate it so that only the last lines are retained:

– Example #1: Check every 15 minutes if the file size is greater than 5 GB and if so empty it:

*/15      *       *       *       *       [ $(du -k .xsession-errors | awk '{ print $1 }') -gt 5000000 ] && >/home/$(whoami)/.xsession-errors

– Example #2: Do the same check, but instead of emptying the entire log, keep the last 10,000 lines:

*/15      *     *       *       *       [ $(du -k .xsession-errors | awk '{ print $1 }') -gt 5000000 ] && tail -10000 /home/$(whoami)/.xsession-errors > /home/$(whoami)/.xsession-errors

Disable writes on .xsession-errors file

If you want to forget about this log because in normal operation you are not interested in its debugging information, you can redirect to /dev/null everything that is written to it and thus always keep a size of 0 bytes. For this you can edit the /etc/X11/Xsession configuration file of the X Window system and locate the following line:

ERRFILE=$HOME/.xsession-errors

Replace it with:

ERRFILE=/dev/null

You can also delete the .xsession-errors file and create a symbolic link to /dev/null instead in order to get the same result:

$ rm .xsession-errors
$ ln -s /dev/null .xsession-errors

The problem is that when you restart the session the symbolic link will be replaced back by a regular file and will start to grow again. To avoid this you must add the following lines to the .bashrc script in your home directory:

# If the .xsession-errors file is not a symbolic link, delete it and create it as such
if [ ! -h $HOME/.xsession-errors ]; then
 /bin/rm $HOME/.xsession-errors
 ln -s /dev/null $HOME/.xsession-errors
fi

Finally, there is another way which consists in setting the immutable attribute to the file, which will prevent to write anything to it by any user or process. This can cause system unexpected behavior, so it should be done with caution:

$ sudo chattr +i .xsession-errors


 

About the author

Daniel López Azaña
Freelance AWS Cloud Solution Architect & Linux Sysadmin

Entrepreneur, a generator of ideas and restless mind. Passionate about new technologies, especially Linux systems and Open Source Software. I also like to write about Technology News, Cloud Computing, AWS, DevOps, DevSecOps, System Security, Web Development and Programming, SEO, Science, Innovation, Entrepreneurship, etc.

DanielHow to prevent the .xsession-errors file from growing to a huge size

Related Posts

17 comments

Join the conversation
  • Robert - 15/10/2017 reply

    It appears that this part of your cron job commands don’t work:

    (du -k .xsession-errors | awk ‘{ print $1 }’) -gt 5000000

    I get:

    bash: syntax error near unexpected token `-gt’

    …when running just that part of the command.

    Daniel - 16/10/2017 reply

    Hi Robert, please note the brackets ([ ]) around as they are very important for the command to work. They are equivalent to the test builtin bash command, so if you don’t use them the -gt comparison operator doesn’t make sense and you get the error message you mentioned.

  • Jim Lewis - 14/05/2018 reply

    This doesn’t seem to be working on my Fedora 26 system. First, deleting the .xsession-errors file doesn’t reclaim the space which seems to be another separate bug. I put in the symbolic link code (that’s pretty clever BTW) and at first I thought it worked but the space used has just jumped up another 5G. I’m now at 82% on /home. The bad thing is this is a server and MUST stay up 24/7/365. A reboot is out of the question. If there are any ideas I would sure like to hear them. Note that this machine/OS is working absolutely great in every other respect. This is my only (known) problem.
    Thanks! Jim Lewis, RHCSA, LPIC-1, Linux book author, video game writer, blah blah blah …

    Daniel - 23/05/2018 reply

    Hi Jim, are you sure .xsession-errors file is responsible for your filesystem’s growth? If it takes 5 GB and you delete it I can’t find any reason why space shouldn’t be released. I don’t think it’s a Fedora bug, but it must be related to the filesystem you are using in /home, probably ext4, which is independent of the chosen Linux distribution. Maybe you have a filesystem corruption there (try to run fsck), or maybe you have a hard link to that file which causes the inode not to be released when you delete it.

    Marc - 16/07/2020 reply

    I can. Open file descriptors. You can delete the file all you want, but unless a reboot takes place or you truncate the file descriptors (or replace them with gdb – a daunting task indeed) the space won’t be reclaimed. Search for ‘linux recover space deleted file open descriptor’ to find out how to truncate the handles.

  • Karan Nage - 21/08/2018 reply

    Hello Daniel sir
    I have Linux 6.0 enterprise server having 700 client login which on cent OS is running at client maching Students are working and performing their assignments using as c,c++,java,all programming language’s at running lab when any c or cpp or java or any program in any pl goes infinite loops that time many xsession.errors and xesession.error.old file created n clients server architecture stop, hanged mode. Please give a shell scripts of its solution its invokes every hours and delete this file automatically without hesitate of client login data m waiting ur positive response

  • Karan Nage - 22/08/2018 reply

    Hello Daniel sir
    I have Linux 6.0 enterprise server having 700 client login which on cent OS is running at client maching Students are working and performing their assignments using as c,c++,java,all programming language’s at running lab when any c or cpp or java or any program in any pl goes infinite loops that time many xsession.errors and xesession.error.old file created n clients server architecture stop, hanged mode. Please give a shell scripts of its solution its invokes every hours and delete this file automatically without hesitate of client login data m waiting ur positive response

  • José - 17/09/2018 reply

    Hola, ayer me dio por probar lo de cambiar la ruta del ERRFILE a /dev/null y a partir de ahí, al encender el ordenador, después de ver el logo de kubuntu la pantalla se ponía en negro y no podía hacer nada.
    Como no hice otras cosas raras, desde una versión live he podido abrir el archivo, volver a escribir la línea como era originalmente y se ha solucionado.
    Por si a alguien más le pasa.

  • Tina - 22/02/2019 reply

    Cool post … thanks for this. Is there a way to stop a certain programm from writing to .xession-errors?

    Daniel - 06/03/2019 reply

    If it runs as a regular user you can properly set permissions in order to ban user’s write access to that file. It it runs as root it is more dificult, you should use quotas/cgroups and see if this is possible in your specific case.

  • Gábor - 04/04/2019 reply

    If you simply remove the .xsession-errors file, the space is not automatically reclaimed. This is the normal behavior of extX filesystems, because a file can still remain open after being deleted, and deletion does not actually take place until the file is not closed. Emptying the file (> .xsession-errors) is a better solution as it modifies and truncates the file in place.

    Setting the file immutable with chattr +i is a bad solution, because in this case another file will be opened in your temp folder, possibly filling your memory with garbage (if you are not interested in what gets there.)

  • Fitzcarraldo - 12/10/2019 reply

    Regarding your Example #2 to prevent .xsession-errors from growing out of control, the shell will first truncate the output file to be empty, then it will copy the last 10000 lines of the now empty file into the file. This leaves you with a zero line file, until the logger starts adding to it again. To fix your cron job you could either use a temporary file or the sponge command from moreutils. I chose to do the latter:

    */15 * * * * [ $(du -k /home/$(whoami)/.xsession-errors | awk ‘{ print $1 }’) -gt 5000000 ] && tail -n 10000 /home/$(whoami)/.xsession-errors | sponge /home/$(whoami)/.xsession-errors

  • Joshua - 21/04/2020 reply

    Thanks for this!

  • Martins - 06/08/2020 reply

    After setting
    ERRFILE=/dev/null
    in /etc/X11/Xsession on Ubuntu 19.10, GUI doesn’t start. Had to revert it.

  • Olaf - 06/01/2021 reply

    Similar thing here: After setting
    ERRFILE=/dev/null
    I could not log in and the gui login screen froze (Ubuntu 20.04 LTS).
    Had to start an alternate parallel console based session with to edit and revert back.

    I do appreciate anybody helping. However, the problem with such advice as in the article is that you need additional skills if something goes wrong. Fatal X server errors are always a big problem as they make it harder to work on it if you don’t know emergency workarounds. Remember that most of us aren’t “routine hackers” and just want a remedy for a problem that concerns everyone.
    I do not believe that all the methods mentioned in the articled were really tested.

    Francisco - 09/05/2021 reply

    I had the same error, so I tried adding
    `ERRFILE=/dev/null`
    on the previous line to the one that says
    `exec >>”$ERRFILE” 2>&1`
    and it seems to be working ok so far.

  • thedude - 24/06/2021 reply

    thank you so much for this article. it has helped me out.
    In my case I also heavily use the standby feature and an open VLC session caused that log file to grow by dozens of MB per sec. After closing VLC, the log file stopped growing.
    vdpau_chroma filter error: video mixer rendering failure: An invalid handle value was provided

Leave a Reply

Your email address will not be published.