lightdm uses a hardcoded path to .xsession-errors, please make it configurable

Bug #1001035 reported by Nahuel Greco
50
This bug affects 10 people
Affects Status Importance Assigned to Milestone
Light Display Manager
Triaged
Wishlist
Unassigned
lightdm (Ubuntu)
Triaged
Wishlist
Unassigned

Bug Description

LightDM uses always $HOME/.xsession-errors as the log file because is harcoded in xsession.c. But sometimes you want to use a logfile outside your $HOME, suposse your $HOME is in an SSD and you want to minimize writes, so you want to put it in /tmp/${USER}_xsession-errors for example. If you try to make a $HOME/.xsession_errors -> /tmp/{$USER}_xsession-errors symlink to cheat LightDM, then LightDM will recreate the $HOME/.xsession_errors file and the hack will not work.

LightDM _always_ recreates $HOME/.xsession_errors and you can't change it without recompiling. So, I think this log file needs to be configurable, or at least preserve the symlink if one is present.

Ubuntu 12.04 LTS
LightDM 1.2.1-0ubuntu1

Changed in lightdm (Ubuntu):
importance: Undecided → Wishlist
Changed in lightdm:
importance: Undecided → Wishlist
status: New → Confirmed
Changed in lightdm (Ubuntu):
status: New → Triaged
Revision history for this message
Kirill Elagin (kirelagin) wrote :

Uh, this drives me crazy.
I've spent half an hour trying to find out what's happening with my .xsession-errors symlink and tracked it down to lightdm itself.

I believe lightdm shouldn't touch this file at all — let scripts in Xession.d adjust everything.

Revision history for this message
DmitryKX (alex-custov) wrote :

I second this

Revision history for this message
Jeremy Bícha (jbicha) wrote :

GDM 3.6 uses $XDG_CACHE_HOME/gdm/session.log (which by default is ~/.cache/gdm/session.log). If somebody wants to change the default location to minimize writes, it would be more effective for them to just need to change a single environment variable.

See also https://live.gnome.org/GnomeGoals/XDGConfigFolders

Revision history for this message
David Biesack (david-biesack-sas) wrote :

I log onto a couple different machines using my common network account (i.e. a shared HOME).
I really need a way to set my .xsession-errors file to be host specific, so that my concurrent
sessions don't stomp on each other.

I recommend a boolean configuration option for lightdm.config to use a
$HOME/.xsession-errors.$HOST if it exists.

Changed in lightdm:
status: Confirmed → Triaged
Revision history for this message
Sergio Gelato (sergio-gelato) wrote :

I also find it the current lack of flexibility highly inconvenient. However, none of the alternatives proposed in the comments above really cut it as far as I'm concerned. Here is how I'd like to be able to set up our desktops (users' home directories are on network shares and have quota imposed on them):

* xsession-errors to a local filesystem, *not* to the home directory;

* automatic log rotation (some users hardly ever log out, there needs to be a way to keep the log file from growing without bound);

* support for multiple concurrent sessions by the same user, even on the same computer (e.g., VNC sessions, sessions with different display depths, etc.; other changes to lightdm may be needed to fully support this);

* log filtering and compression (to deal with buggy programs that output the same message in a loop; the latest incident here involved chromium-browser);

* timestamping of log entries.

Most of this would be easy if there was an option to pipe the output to an external program (e.g., /usr/bin/logger or some wrapper script around it). Make that configurable by the administrator and/or the user. LightDM could pass additional information as command line arguments or environment variables.

Revision history for this message
Andrew Kravchuk (awkravchuk) wrote :

Any update on this? I'd love to move xsession-errors file out of my SSD to minimize writes.

Revision history for this message
Gerard Weatherby (gweatherby) wrote :
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.