nspluginwrapper fills .xsession-errors until disk space is exhausted

This bug happened to me last night. System is running Ubuntu 10.04.2 LTS, firefox 3.6.13 with flashplugin 10.2.152.27ubuntu0.10.04.1

Seen also on Ubuntu 10.10:

flashplugin-nonfree 10.2.152.27ubuntu0.10.10.1
firefox 3.6.13+build3+nobinonly-0ubuntu0.10.10.1
nspluginwrapper 1.2.2-0ubuntu7

*** NSPlugin Viewer *** WARNING:(/build/buildd/nspluginwrapper-1.2.2/src/npw-viewer.c:1017):invoke_NPN_InvalidateRect: assertion failed: (rpc_method_invoke_possible(g_rpc_connection))

The error message are being produced at a rate of about 60 per second on my machine.

(Also Ubuntu 10.10.)

I noticed the backup of my home directory was taking hours rather than minutes and tracked it down to a 2.5 GB ".xsession-errors.old" file which contained over 13,000,000 lines of:

*** NSPlugin Viewer *** WARNING:(/build/buildd/nspluginwrapper-1.2.2/src/npw-viewer.c:1017):invoke_NPN_InvalidateRect: assertion failed: (rpc_method_invoke_possible(g_rpc_connection))

This is killing my backups, killing my hard drive space, and killing my CPU.

Ubuntu 10.04, Firefox 3.6.13

Also creates multi-GB .xsession-errors file.

A workaround for affected users:

According to http://www.fedoraforum.org/forum/showthread.php?t=218008
--------------------------
Use small script and put it into the startup apps, it seems xinit does not create a new xsession-errors log once it has been erased at session startup.

Code:
#!/bin/sh
# deletes ~/.xsession-errors at startup so it does not write gigabytes of debug info
rm -f ~/.xsession-errors

Hi, same issue here, i've this file the size of a DVD... And it's not that easy to pinpoint the culprit. It is a pretty bad issue IMHO.

I used this:

$ find /home/YOUR_NICK -iname "*" -mmin -2 -print

It will show the files accessed in the last 2 minutes in your home (replace YOUR_NICK with your login)

Best regards,
Yannick

and some commands to show how bad NSplugin is impacting the log file here (number of lines in the log file and the size of the file):

$ grep "NSPlugin" ~/.xsession-errors | wc -l
4415936

$ grep "NSPlugin" ~/.xsession-errors.old | wc -l
20999800

$ ls -l ~/.xsession-errors
-rw------- 1 yannick yannick 864560478 2011-04-13 14:48 /home/yannick/.xsession-errors

$ ls -l ~/.xsession-errors.old
-rw------- 1 yannick yannick 3885393173 2011-03-30 19:28 /home/yannick/.xsession-errors.old

Running Ubuntu 10.04 LTS 64 bits

A working workaround for me is to install the 64 bits version of flash. (which is BETA)

I get the same exact problem when I use remminas, connect to an rdp client or two. Leave them sit there overnight, sometimes a few days. Then your pc crashes out of disk space.

I see something similar to the following:
SSL: Write IO_ERROR

It filled up 860GB out of my 1TB drive. Nasty...

Not so great workaround to avoid a reboot if you can catch it in time:
open up a terminal:
tail -f .xsession-errors
if you see it start going insane with the error's that appear for you, close the app responsible
delete .xsession-errors
Log off
Log On

This is devastating on my work workstation, because some programs need to save things, and cannot. Then they won't even start up on next reboot, such as virtualbox. your xml config files get ruined. luckily I had my virtual hard drives on a separate physical drive.

Linux Mint 11

This seems to be a lot more wide-spread than just this particular package. I have found that occasionally deleting the .cache directory in my home folder seems to solve a lot of this. I keep having this file fill up a 750GB partition in less than 24 hours. Filling 750 GB, making me find the file, delete it, and then have to reboot to continue working is patently ridiculous. It's flatly unacceptable for a server and only marginally so for a workstation.

When I google for "xsession-errors filling hard drive", I get lots of hits from multiple linux distros, so this isn't isolated to Ubuntu or Debian. And the date range is quite extensive as well from 2005 to the just a few weeks ago. So this has been happening to a lot of people, with a lot of linux distributions, for a very long time.

I think the fundamental solution is to change how the logging for xsession-errors behaves. Given the involvement of applications from WINE to the gnome desktop, I don't see fixing every single application as a viable solution. Too many users need help NOW and, frankly, this has been happening for at least 6 years, if not longer. That's just not right. So that brings the logic trail back around to fixing how the xsession-error log file is handled and how those error messages are logged.

Suggestion #1 There should be a file size limit and once that'us s reached, it starts to overwrite.

Suggestion #2 Implement the "This error repeats 147 more times" in the error log rather than logging each error.

Suggestion #3 Point the log file to /dev/null by default and let the user point it elsewhere at their own risk. This is perhaps the quickest fix and easiest to implement as it is would be a slight change to the Xsession file in /etc/X11. Change the location and add some comments explaining the possible issues along with directions on how to change it back.

> Suggestion #1 There should be a file size limit and once that's
> reached, it starts to overwrite.

> Suggestion #2 Implement the "This error repeats 147 more times" in the
> error log rather than logging each error.

Neither of these are practical solutions. The nature of .xsession-errors is that it captures the stdout and stderr output of programs *that have no knowledge of .xsession-errors*. I.e., this is a mechanism to make it possible to debug problems in programs run from the desktop without changing (and possibly without being *able* to change) the program you need to debug. A logging API that would support log rotation or elimination of duplicate messages is not a replacement for this.

If any program in the desktop is spewing errors to stderr/stdout fast enough to fill up your disk, that's a serious bug in that program. However, despite using nspluginwrapper extensively here, I've never seen the bug in question.

$ grep -i nsplugin ~/.xsession-errors
$

Kanaida, I've got the same bug and have Remmina running as well. It is actually a freeRDP bug.

http://sourceforge.net/mailarchive/forum.php?thread_name=4DE6E66C.502%40163.com&forum_name=remmina-common
http://sourceforge.net/tracker/index.php?func=detail&aid=3315749&group_id=278330&atid=1181674

It will be fixed with the freerdp release.

Shouldn't this bug be broadened a bit? Allowing .xsession-errors to grow indefinitely without any kind of log rotation in place is a design flaw. The file should be rotated and old files compressed. A gzipped >5GiB log file takes up about 20MiB on disk.

Attaching a gzipped log file which repeats, among other things, the string "Authentication deferred - ignoring client message" about 110000 times a second towards the end. Something else is repeated loads of times somewhere in the middle as well. This should not be allowed to happen.

On Fri, Nov 09, 2012 at 03:42:20PM -0000, Benjamin Tayehanpour wrote:
> Shouldn't this bug be broadened a bit? Allowing .xsession-errors to grow
> indefinitely without any kind of log rotation in place is a design flaw.
> The file should be rotated and old files compressed.

It doesn't work that way. This file is attached to the stdout/stderr of
your X session. Rotating the file doesn't change the fact that your entire
desktop has an open file descriptor to the old file and will continue
writing to it, even after deletion.

This could theoretically be solved by having stdout/stderr attached to a
pipe instead and running a service on the other end of that pipe that
handles logging and rotation; but it's still just Not Ok for software to be
spewing this level of noise to stderr, wherever it's going.

@konaya I just wrote a post in the forums of what I found to be the root cause of this issue. In my logs it appeared as if what caused the log file to grow so large was a brute-force attack. The log filling up is a result of the failed attempts to authenticate to your system's VNC server. After a certain number of failed attempts it appears as if the VNC server just starts rejecting the attempted connections without giving them a chance to authenticate (which is good). Luckily, if these are still happening then most likely they haven't hacked you yet. Check out my post if you are interested.

http://ubuntuforums.org/showpost.php?p=12507381&postcount=9