Daniel López Azaña

Theme

Social Media

Blog

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

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

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
Daniel López Azaña

About the author

Daniel López Azaña

Tech entrepreneur and cloud architect with over 20 years of experience transforming infrastructures and automating processes.

Specialist in AI/LLM integration, Rust and Python development, and AWS & GCP architecture. Restless mind, idea generator, and passionate about technological innovation and AI.

Related articles

Ctrl+S

Unlock Linux command line after pressing Ctrl+s in Bash

Since the key combination Control+s is widely used as a shortcut to save files in GUI applications such as text editors, image editors, web browsers, etc. sometimes you are betrayed by your subconscious when you are working from the Linux command line and you use that same key combination when you are for example editing a Vim document when trying to save it. Then you notice that no key answers, the shell is locked and you can no longer do anything else in it.  Even worse, you get a cold sweat because you can’t continue editing your document and you can’t save the changes.

April 27, 2017
fatrace command man page

Fatrace command: how to know in real time which processes are writing to a file

It is usually easy to know which process or processes are writing to a given file in Linux, since we either know its origin and its nature beforehand (for example the Apache access_log), or we can easily find it out with the fuser or lsof commands. However, sometimes it will happen that although we know the role and purpose of a file, there are so many applications accesing it simultaneously that it is very difficult to know which of them is the one that reads/writes the most or does so in a precise moment. Knowing this would be very useful to learn for example why a log file is growing excessively or which application is making an abusive use of system resources, either by mistake or intentionally.

June 23, 2017
linux-penguin-inside-a-box-tar-gz

15 most useful Linux commands for file system maintenance

One of the most common and tedious tasks of a sysadmin is to prevent file systems become completely full, because when a server runs out of space the consequences are unpredictable. Depending on how you structured the root file system and if it is divided into different partitions or volumes, those consequences will be more or less severe, but in any case undesirable.In any case it is always better to be safe than sorry, so use tools that perform automatic log rotation as logrotate and custom scripts to monitor and conduct periodic emptying actions to prevent file systems to get full. However, still using these prevention methods it is for sure it will be many times when you will have to act manually to troubleshoot problems.

October 1, 2014

Comments

Robert October 15, 2017
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 October 16, 2017
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 May 14, 2018
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 May 23, 2018
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 July 16, 2020
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 August 21, 2018
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 August 22, 2018
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é September 17, 2018
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 February 22, 2019
Cool post ... thanks for this. Is there a way to stop a certain programm from writing to .xession-errors?
Daniel March 6, 2019
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 April 4, 2019
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 October 12, 2019
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 April 21, 2020
Thanks for this!
Martins August 6, 2020
After setting ERRFILE=/dev/null in /etc/X11/Xsession on Ubuntu 19.10, GUI doesn't start. Had to revert it.
Olaf January 6, 2021
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 May 9, 2021
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 June 24, 2021
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

Submit comment