desktop-packages team mailing list archive

["Christopher M. Penalver" <christopher.m.penalver@xxxxxxxxx>]

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