Consolidate handling of ~/.xsession-errors

[Martin Pitt]

Hi all,

in the recent distro team meeting we had a short discussion about how
to handle ~/.xsession-errors. For the record, this file usually
receives stderr from X programs which run in the background, so it is
a valuable diagnostic tool if something goes wrong.

At the moment the handling for this is highly inconsistent:

- gdm (Ubuntu) has always just removed the entire file on login, thus
  all logs from the previous session are gone.
- With kdm/xdm, dapper did never remove/truncate the file, which
  caused disk space DoS with programs where logging has gone wild. See
  https://launchpad.net/bugs/60448.
- In edgy, we mitigated that by truncating the file to .5 MB on login.
  However, that will fail if /home and /tmp are on the same partition,
  which is (unfortunately) our default configuration.
- In feisty this change got lost again, since for some reason edgy
  shipped /etc/X11/Xsession in the xorg source package, and dapper and
  feisty ship it in the xinit source package.

This mess deserves a cleanup and a consistent handling across
dapper/edgy/feisty and Ubuntu/Kubuntu/Xubuntu. Thus we should agree to
a strategy how to deal with this file.

The following proposals were made (all of this will happen at session
start). I mention the pros (+) and cons (-) that came up so far.

(1) Rotate the existing file to ~/.xsession-errors.old and start with
    a new one.

    + Trivial to implement.
    + Similar to system log file rotation.
    - Doesn't clean up after a disk space exhaustion, requires a
      second login.
    - After that second login you lost the *entire* log.
      more tricky.
    - Creates just another file in ~, as well as unexpectedly
      overwriting an already existing .old file that the user might
      have created for bug reporting purposes (admittedly this is a
      corner case).

(2) Keep the last n kB of ~/.xsession-errors and truncate everything
    before.

    + Keeps the traditional single-file approach without new clutter.
    + Cleans up immediately after disk space exhaustion.
    + History is never completely thrown away, so you can still access
      logs even after several failed logins.
    - Nontrivial to implement: Creating a temporary file on disk
      doesn't work if there is no space left, thus the recent part
      (Edgy: 512 kB) must be temporarily loaded into memory, which is
      not easy in shell. (DATA=$(< file) breaks with 0-bytes, for
      example).
    - Does not keep apart logs from different sessions (although that
      can be rectified with adding an initial log statement '---
      session start at <time> ---')

(3) Keep one log per session, and last n logs (like logrotate) and
    truncate each of them to the last n KB.

    + Completely consistant with sytem log handling (apart from
      truncation).
    + Cleans up immediately after disk space exhaustion.
    + You can still access logs even after several failed logins.
    - Lots of new files in user's home (cluttering backups, etc.).
    - Even harder to implement than (2).

Feedback, discussion, and more strategies are greatly appreciated!

Have a wonderful weekend,

Pitti

-- 
Martin Pitt        http://www.piware.de
Ubuntu Developer   http://www.ubuntu.com
Debian Developer   http://www.debian.org

In a world without walls and fences, who needs Windows and Gates?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20061208/0c0a3368/attachment.pgp