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.


Error: Your Requested widget " ai_widget-6" is not in the widget list.
  • [do_widget_area above-nav-left]
    • [do_widget_area above-nav-right]
      • [do_widget_area footer-1]
        • [do_widget id="wpp-4"]
      • [do_widget_area footer-2]
        • [do_widget id="recent-posts-4"]
      • [do_widget_area footer-3]
        • [do_widget id="recent-comments-3"]
      • [do_widget_area footer-4]
        • [do_widget id="archives-4"]
      • [do_widget_area logo-bar]
        • [do_widget id="oxywidgetwpml-3"]
      • [do_widget_area menu-bar]
        • [do_widget id="search-3"]
      • [do_widget_area sidebar]
        • [do_widget id="search-4"]
        • [do_widget id="ai_widget-2"]
        • [do_widget id="categories-5"]
        • [do_widget id="ai_widget-3"]
        • [do_widget id="ai_widget-4"]
        • [do_widget id="ai_widget-5"]
      • [do_widget_area sub-footer-1]
        • [do_widget id="text-4"]
      • [do_widget_area sub-footer-2]
        • [do_widget_area sub-footer-3]
          • [do_widget_area sub-footer-4]
            • [do_widget_area upper-footer-1]
              • [do_widget id="search-2"]
              • [do_widget id="recent-posts-2"]
              • [do_widget id="recent-comments-2"]
              • [do_widget id="archives-2"]
              • [do_widget id="categories-2"]
              • [do_widget id="meta-2"]
            • [do_widget_area upper-footer-2]
              • [do_widget_area upper-footer-3]
                • [do_widget_area upper-footer-4]
                  • [do_widget_area widgets_for_shortcodes]
                    • [do_widget id="search-5"]
                    • [do_widget id="ai_widget-6"]
                  • [do_widget_area wp_inactive_widgets]
                    • [do_widget id="wpp-2"]
                    • [do_widget id="text-1"]
                    • [do_widget id="recent-posts-3"]
                    • [do_widget id="categories-3"]
                    • [do_widget id="archives-3"]
                    • [do_widget id="icl_lang_sel_widget-3"]

                  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.