GNOME Bugzilla – Bug 704879
gdm should have option for per-host .xsession-errors file
Last modified: 2018-05-24 10:54:45 UTC
For those of us who have a shared network home directory, logging onto two machines causes them to stomp on the same .xsession-errors file. (However, I want to reuse most of the rest of my X config, i.e. ~/.config). Thus, it would be nice to have a per-host .xsession-errors file or some other way to configure the .xsession-errors file location. See also https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/382879 which shows how editing /etc/X11/Xsession (or /etc/gdm/Xsession) allows configuring the error file ERRFILE. gdm should have some similar capability
As of gdm 3.6, gdm's user log saves to $XDG_CACHE_HOME/gdm/session.log by default. *** This bug has been marked as a duplicate of bug 627939 ***
Please clarify how this is a dup. I see it as a different problem. The log file is still a fixed location that I can't make host-specific until after it has been opened/written to. Moving the file to $XDG_CACHE_HOME/gdm/session.log does not help for multiple concurrent logins which both have the same $XDG_CACHE_HOME value (i.e. ~/.cache on a network/nfs home directory.) While I can change XDG_CACHE_HOME in my session startup script, that may be "too late". It also means that the concurrent sessions cannot share the cache (which may be better in many ways, but is still not the default as far as I can see, unless something else specifies host-specific $XDG_CACHE_HOME ) I looked at https://live.gnome.org/GnomeGoals/XDGConfigFolders but I don't see how this "helps avoid clobbering the log files when shared home directories are used." Perhaps I missed it. It is not clear if it is valid for me to change this in my session startup script. For example, setting it in my session startup script will not affect the environment that the dm (gdm, lightdm, etc.) has created and passed to other processes before my session script runs.
I apologize for not reading closely enough. The Launchpad bug was fixed but what you're describing is a totally different issue.
we write to journald now if available, which is a system specific journal service. ~/.cache is a fallback if journald isn't available, so things should be square now for the most part.
https://www.gnome.org/?s=journald shows no hits; https://bugzilla.gnome.org/buglist.cgi?quicksearch=journald shows nothing related. Can you elaborate? I suppose https://wiki.gnome.org/GnomeGoals/XDGConfigFolders merits updating to reflect this? Of course, if journald is not available, this problem still exists. I run Ubuntu 13.04 on my desktop and gdm on a recent CentOS distro, both sharing the same $HOME. I don't think jounrald is running in either (but I'm not sure how to to be sure. I see no journald process; /run/log does not exist.) So I still don't see how this is resolved/fixed.
Jeremy, do you know if Ubuntu is going to enable journald at some point?
No, I don't think journald is easily runnable without systemd as system init. Ubuntu (and I assume Debian too) is stuck with systemd 204 since 205+ has tied logind even deeper into systemd.
I solved that 15 years ago, back in the days BEFORE Gnome was even a thing! In my xsession/xinitrc startup scripts I move the .xsession-errors file to a file that includes the hostname (or whatever else you want, like a rotating logfile name). Here is the relevant code I am currently using. It also saves the previous session errors too, which has been a great help at times. Just a shame GTK clients are so &^$^&% verbose! # Session is an environment variable passed from ".xsession". # Typically it is the name of the machine we are running the display on # But it may be a special session such as: "vnc", "xmon", "gnome" [ -z "$SESSION" ] && SESSION=$SHORTHOST export SESSION # Set up Error Log file... log=".xerrors-$SESSION" rm -f "$log-prev" [ -f "$log" ] && mv "$log" "$log-prev" for old_log in .xsession-errors .cache/gdm/session.log do [ -f "$old_log" ] || continue mv -f "$old_log" "$log" break done exec >> "$log" 2>&1 # save the errors here (from here on)
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gdm/issues/156.