David Grossberg, one could extrapolate your position to every application that logs information. This viewpoint is unfortunately a cart before the horse. For example, why as a software maintainer (which viewed by all maintainers of every application, driver, etc. that this is an application issue, i.e. the log is filling up because either the sheer volume of the information, and/or the applicability of the log messages to maintaining the application) even worry about too verbose logging? Or logging things that are most important when reviewing the applicable log? Why don't all package developers have every possible thing spew out into any log they can, generating hundreds of GB/s, grinding your OS to a crawl, and giving an overwhelming amount of irrelevant information (low signal to noise ratio)? But don't worry about it, the operating system will take care of that, and people should just get used to manually intervening in log capture modifications of every possible application they have installed (~2566 installed on my instance so that's a lot of work!), but fast enough before the logging kicks in and stops their efforts due to the OS spending all its resources on just handling logs...
Long story short, file a report against the offending application and the bug in it will get addressed. Thank you for your understanding. Helpful bug reporting tips: https://wiki.ubuntu.com/ReportingBugs -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to remmina in Ubuntu. https://bugs.launchpad.net/bugs/870138 Title: .xsession-errors fills hard drive until system crashes Status in remmina package in Ubuntu: Invalid Bug description: This seems to be a very wide spread problem. 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 FlashPlayer to Remina to NSwrapper to 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. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/remmina/+bug/870138/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
