~/.xsession-errors fill up root partition

[AussieBear]

All,

I am a frequent PC gamer and use the wine system to play Windows games.

However, I have noticed some games using wine cause the ~/.xsession-errors
file to grow rather huge and even blow out my root partition.

I could have moved /home to a different partition, however the file growth problem
would still exist.

I tried creating links between ~/.xsession-errors and /dev/null which worked for
a while.  Then the link got "magically" replaced as a regular file and the problem
came back.

I noticed that simply removing the file after a gaming session was not enough to actually
free up space until I rebooted my machine. Not something I want to do just because I was
playing games...

Then I found this link:

https://marc.waeckerlin.org/computer/blog/get_rid_of_xsession-error_that_s_filling_up_the_home_directory

A simple one line fix of the /etc/X11/Xsession file that solved the problem. Like the
link to /dev/null, just permanent.

Now I can play games weeks on end without rebooting.

Hope you find this useful.

Cheers,

Aussiebear.

[YouCanToo]

Nice information, thanks

[ternor]

On my system the file /etc/X11/Xsession does not contain the text quoted in that article.  My guess is that PCLinuxOS uses a different file to create the errors file.  I installed the 2012.08 kde iso and the system is updated.

The only reference in that file to the 'errfile' is in a section beginning with the line "if [ -z "$GDMSESSION" ]; then."

[YouCanToo]

On my system the file /etc/X11/Xsession does not contain the text quoted in that article.  My guess is that PCLinuxOS uses a different file to create the errors file.  I installed the 2012.08 kde iso and the system is updated.

The only reference in that file to the 'errfile' is in a section beginning with the line "if [ -z "$GDMSESSION" ]; then."

That is the pace that you want to look. You will want to find this line exec > "$errfile" 2>&1 and comment it out. Then add this line  exec >> /dev/null 2>&1 

It should look something like this when you are done

if [ -z "$GDMSESSION" ]; then
    # redirect errors to a file in user's home directory if we can
    for errfile in "$HOME/.xsession-errors" "${TMPDIR-/tmp}/xses-$USER" "/tmp/xses-$USER"
        do
        if ( umask 077 && cp /dev/null "$errfile" 2> /dev/null )
            then
            chmod 600 "$errfile"
#           exec > "$errfile" 2>&1
             exec >> /dev/null 2>&1
            break
        fi
    done
fi

When you have made the changes be sure to save your file.

[ternor]

Thanks.  Done.

[YouCanToo]

Even though I made the changes to /etc/X11/Xsession file, it appears not to work as advertised.  I cleared out the .xsession-errors file in my home directory and today it was back.

-rw------- 1 dwmoar dwmoar 17941 Dec 29 00:53 .xsession-errors

After a bit of thinking I decided to use a cron job to prevent it from growing out of control.

I created a cron job as the root user.

create a file called root in /var/spool/cron

To create that file open a console window and change to the cron directory

cd /var/spool/cron

Now as the root user create the file called root using the following command

touch root

Now we need to add the following line to our newly made file. So open the file called root.

nano root

Copy and paste the following line

@hourly cat /dev/null > /home/your-home-directory/.xsession-errors

Change the your-home-directory to that of your username.  When you have completed this step we need to save and close the text editor.

close nano by pressing both your control and x key at the same time, press Y, and return and nano will save the file and close.  Check that we have the correct permissions for our newly created file

ls -la root

You should see something like this

-rw------- 1 root root 54 Dec 29 21:11 root

if you have anything beside the -rw------- then we need to use the following command to change it to the correct permissions.

chmod 600 root

We want to restart the cron service, so issue the following command

service crond restart

You should see something like this

[root@localhost cron]# service crond restart
Stopping crond:                                                                                           [  OK  ]
Starting crond:                                                                                            [  OK  ]
[root@localhost cron]#

Great we are good to go. Go ahead and close your terminal window. Now anytime your system is running it will keep the .xsession-errors file under control

Cron will reset the file pointer of the .xsession-errors file back to zero every hour. This is what mine now looks like

-rw------- 1 dwmoar dwmoar 0 Dec 29 15:37 /home/dwmoar/.xsession-errors

[YouCanToo]

I am beginning to believe that there is a problem in this line in the file

exec >> /dev/null 2>&1

I think that this is causing the problem   exec >> /dev/null 2>&1

In C++ the "<<" or ">>" stands for a bit shift either right or left.  Normally it would be followed by a number referring to the number to be shifted by.  In assembly language you have something called "ROR" and "ROL" to shift bits.  What I don't understand is why you would need to have ">>" in this line. To me it seems that the proper line would be this.   exec > /dev/null 2>&1

Can any one confirm my thought(s) here

[Old-Polack]

I am beginning to believe that there is a problem in this line in the file

exec >> /dev/null 2>&1

I think that this is causing the problem   exec >> /dev/null 2>&1

In C++ the "<<" or ">>" stands for a bit shift either right or left.  Normally it would be followed by a number referring to the number to be shifted by.  In assembly language you have something called "ROR" and "ROL" to shift bits.  What I don't understand is why you would need to have ">>" in this line. To me it seems that the proper line would be this.   exec > /dev/null 2>&1

Can any one confirm my thought(s) here

In bash the > would indicate a write to a file of the given name, overwriting any previous content in that file. The >> would indicate that the write should be in the form of an addendum to the file in question. Being a write to /dev/null, I'd go with the >.

[YouCanToo]

Thanks for the explanation.

[AussieBear]

I am beginning to believe that there is a problem in this line in the file

exec >> /dev/null 2>&1

I think that this is causing the problem   exec >> /dev/null 2>&1

In C++ the "<<" or ">>" stands for a bit shift either right or left.  Normally it would be followed by a number referring to the number to be shifted by.  In assembly language you have something called "ROR" and "ROL" to shift bits.  What I don't understand is why you would need to have ">>" in this line. To me it seems that the proper line would be this.   exec > /dev/null 2>&1

Can any one confirm my thought(s) here

In bash the > would indicate a write to a file of the given name, overwriting any previous content in that file. The >> would indicate that the write should be in the form of an addendum to the file in question. Being a write to /dev/null, I'd go with the >.

You are correct. However, there some subtle differences in the way ">" and ">>" act on the target
file.

Generally, you use ">" to over-write a file (or device in this case).  ">" can also have the side effect
of changing file permissions.  ">>" appends to the file in place, not touching file permissions. 
When writing to a device (/dev/null) it is good form to use ">>".

For completeness, "2>&1" is a redirection of all information written to stderr to the stdout file descriptor.
If you just used "2>1", stderr will be redirected to a file called "1".

This should be right.  It has been a while. Back in the day, I worked a AT&T Bell Labs, so got to
know Unix and its source code rather well...

We used to say "Unix is God's operating system and Emacs is his editor. Vi is a close second".   

Take Care and Be Well,

AussieBear.

[YouCanToo]

Thanks for the additional information AussieBear

When I changed the line from this  exec >> /dev/null 2>&1   to this exec > /dev/null 2>&1
Everything works as I expected it to and no longer wrote anything to the file .xsessions-errors. As can bee seen here.

-rw-------  1 dwmoar dwmoar     0 Jan  3 11:49 .xsession-errors

So far the permissions haven't changed.  The way the line originally was  exec >> /dev/null 2>&1 would keep writing to the
.xsessions-errors file. And it kept growing in size, even though I had zeroed out the .xsession-errors file.

[AussieBear]

YouCanToo,

Interesting indeed!   My Xsession file uses ">>" and ~/.xsession-errors
has remained size zero.  Of note, every time I reboot/logout-login the
~/.xsession-errors file gets "touched" from somewhere.

Are you still using the cron job to fiddle with the .xsession-errors file?

Ultimately, what is important is that ~/.xsession-errors does not grow to
fill /.

Cheers,

AussieBear.

[YouCanToo]

YouCanToo,

Interesting indeed!   My Xsession file uses ">>" and ~/.xsession-errors
has remained size zero.  Of note, every time I reboot/logout-login the
~/.xsession-errors file gets "touched" from somewhere.

Are you still using the cron job to fiddle with the .xsession-errors file?

Ultimately, what is important is that ~/.xsession-errors does not grow to
fill /.

Cheers,

AussieBear.

On a couple of machines (2) I am still using the cron job. The rest of my machines (5) I have modified the Xsession file and am only using it. So far the Xsession change is working fine.