Bug 985922 - /etc/gdm/Xsession logs everything in /var/log/messages
/etc/gdm/Xsession logs everything in /var/log/messages
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: gdm (Show other bugs)
23
Unspecified Linux
unspecified Severity medium
: ---
: ---
Assigned To: Ray Strode [halfline]
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-18 09:55 EDT by udo
Modified: 2017-10-28 07:40 EDT (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-07-19 15:26:42 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
sample messages full of errors (32.79 KB, text/plain)
2014-03-31 17:53 EDT, Marek Zdunek
no flags Details

  None (edit)
Description udo 2013-07-18 09:55:21 EDT
Description of problem:
/etc/gdm/Xsession logs eveyting in /var/log/messages: every hiccup, error and what not of xorg, the gui applets and stuff I run. I recall that in Fedora 17 this stuff came in a file in my home directory instead. now we have a /var/log/messages that should contain just important stuff littered with whatever.

Version-Release number of selected component (if applicable):
gdm-3.8.3-2.fc19.x86_64

How reproducible:
upgrade to F19, use it, check /var/log/messages after a while

Actual results:
All types of messages that do not belong there.

Expected results:
A /var/log/messages file without the noise of the unimportant stuff that does not belong there

Additional info:
Comment 1 udo 2013-07-18 10:08:57 EDT
How to get the old behaviour of logging in .xsession-errors back?
Comment 2 udo 2013-08-16 11:32:14 EDT
Please explain what design decision was the cause of this observation.
Please fix if no design decision was used to obsolete .xsession-errors.
At least respond to let us know what is happening.
Comment 3 udo 2013-10-21 09:32:01 EDT
~/.xsession-errors content in /var/log/messages is U G L Y.
~/.xsession-errors content used to be ignored so why bother to change the location?
bacause what advantage does journalctl have over plain text files?

So please fix this issue so we can at least have a choice. Thank you.
Comment 4 udo 2013-10-30 11:26:54 EDT
After reading a bit I got the idea that systemd might be the cause.
Systemd is becoming some pimped swiss army knife instead of a tool, something I cannot incfluence as it seems. Maybe you should read http://phoronix.com/forums/showthread.php?83420-Fedora-20-Goes-For-No-Default-Sendmail-Syslog&p=351479#post351479 and rest of that thread to understand what some of us might mean.

I request the option to have the very old behaviour of logs (messages, cron, ~/.xsession etc) as they were in Fedora 17. systemd can do anything it likes except changing /that/.
So please be so kind.
Comment 5 Zbigniew Jędrzejewski-Szmek 2013-10-30 11:58:12 EDT
There's not much systemd package can do about this. In the journal those messages are properly separated, 'journalctl --user' shows them nicely.
It is a big improvement over having to hunt down hidden files in $HOME to access logs, which is the motivation for this change. With appropriate filter rules, the syslog daemon might separate them for you.
Comment 6 udo 2013-10-30 12:00:50 EDT
It is a big improvement to have logs in easy text files at known locations for different users and the system daemons, thank you.
Thank you for redirecting the bug to hopefully the correct component.
Comment 7 udo 2014-02-19 11:23:21 EST
Same in Fedora 20.
/var/log/messages is garbage.
Will the real cause please be mentioned?
Will the real cause please be fixed?
Comment 8 udo 2014-03-27 12:58:19 EDT
Any updates? Any info needed? Logs?
Comment 9 Marek Zdunek 2014-03-31 17:53:31 EDT
Created attachment 881111 [details]
sample messages full of errors

same here, log is full of (look attachment)
/etc/gdm/Xsession: Ncat: Connection refused.
one entry every minute
Comment 10 udo 2014-08-15 05:47:45 EDT
Any updates?
Any extra info needed?
Any patches I could test?
Comment 11 Tomas Heinrich 2014-09-05 11:02:56 EDT
Hello.

First: this is not an rsyslog bug. I _think_ this is a GDM bug (to come full circle), if it is a bug at all.

Changing rsyslog's configuration because one source is producing overabundant messages doesn't seem reasonable. Though, as a temporary workaround, you can change rsyslog's configuration to filter these messages out.

I've found a commit[0] that looks responsible for the change. It adds journal as a sink and adds two log levels: LOG_INFO for stdout and LOG_WARNING for stderr.
I think this is part of the problem; this granularity is too coarse. It might not matter for a dedicated file, but for the system log, too much junk is a problem.

Zbigniew, even though journalctl can filter these messages out, they still pollute more general queries. The space journal has for messages is constrained and storing "junk" messages makes useful information to be rotated away.

I have couple of suggestions to consider:
- Make the sink (file vs journal) configurable, not hardcoded
- Add more levels for messages; LOG_DEBUG might be more appropriate for some messages
- Make emission of "debug" messages configurable

[0] https://git.gnome.org/browse/gdm/commit/?id=a505c58cee7c1d4f397fb8c0903cc78221c308b4
Comment 12 Tomas Heinrich 2014-09-05 11:09:09 EDT
Colin, as the author of the change to GDM, could you comment on any of the above?
Comment 13 udo 2014-09-05 11:15:06 EDT
How to get the old behaviour of logging in .xsession-errors back?
/var/log/messages was waaaaayyyyyy cleaner back then.
Comment 14 Tomas Heinrich 2014-09-05 11:27:45 EDT
(In reply to udo from comment #13)
> How to get the old behaviour of logging in .xsession-errors back?

I'm not familiar with GDM, so I can't help you here.
You can at least configure rsyslog not to store them in /var/log/messages. For that, see the documentation at http://www.rsyslog.com/doc/v7-stable
Comment 15 udo 2014-09-05 11:38:43 EDT
Error 404 - Not Found
The site '/doc/v7-stable' does not exist here.

Why is it so hard to fix this essential unix behaviour?
Comment 16 Tomas Heinrich 2014-09-10 10:42:53 EDT
(In reply to udo from comment #15)
> Error 404 - Not Found
> The site '/doc/v7-stable' does not exist here.

A trailing slash is missing.
Comment 17 udo 2014-09-10 11:52:46 EDT
(In reply to Tomas Heinrich from comment #16)
> (In reply to udo from comment #15)
> > Error 404 - Not Found
> > The site '/doc/v7-stable' does not exist here.
> 
> A trailing slash is missing.

Weird, but thanks.
Now what configuration do you suggest *as* *a* *workaround* to restore the pre systemd behaviour w.r.t. the logging?
I.e. no .xsession-errors in /var/log/messages, no crond in /var/log/messages, etc.
Comment 18 Fedora End Of Life 2015-01-09 13:59:28 EST
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 19 Zbigniew Jędrzejewski-Szmek 2015-01-09 14:37:49 EST
I'm working for an (upstream) patch for X to log natively to the journal.
Comment 20 Jaroslav Reznik 2015-03-03 09:58:29 EST
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
Comment 21 udo 2015-03-14 09:45:51 EDT
(In reply to Zbigniew Jędrzejewski-Szmek from comment #19)
> I'm working for an (upstream) patch for X to log natively to the journal.

Will that make the old behaviour (.xsession-errors and the rest in /var/log/messages) possible again?
Comment 22 Zbigniew Jędrzejewski-Szmek 2015-03-14 09:49:43 EDT
(In reply to udo from comment #21)
> (In reply to Zbigniew Jędrzejewski-Szmek from comment #19)
> > I'm working for an (upstream) patch for X to log natively to the journal.
> 
> Will that make the old behaviour (.xsession-errors and the rest in
> /var/log/messages) possible again?

Quite the opposite.
Comment 23 Zbigniew Jędrzejewski-Szmek 2015-03-14 10:00:43 EDT
(In reply to Tomas Heinrich from comment #11)
> I've found a commit[0] that looks responsible for the change. It adds
> journal as a sink and adds two log levels: LOG_INFO for stdout and
> LOG_WARNING for stderr.
> I think this is part of the problem; this granularity is too coarse. It
> might not matter for a dedicated file, but for the system log, too much junk
> is a problem.
Yes, a full range of log levels should be used. When the messages go through stout/stderr this is not  possible, but if we switch to native journal logging, it will happen.

> I have couple of suggestions to consider:
> - Make the sink (file vs journal) configurable, not hardcoded
Logging to a file on disk is going backwards. We have to finish the transition to the new scheme and fix bugs, not add code and user configuration to support something that is obsolete.

> - Add more levels for messages; LOG_DEBUG might be more appropriate for some
> messages
> - Make emission of "debug" messages configurable
Yes. Software should not log "debug" messages during default mode of operation.
Comment 24 udo 2015-03-14 10:22:07 EDT
(In reply to Zbigniew Jędrzejewski-Szmek from comment #22)
> > Will that make the old behaviour (.xsession-errors and the rest in
> > /var/log/messages) possible again?
> 
> Quite the opposite.

Journal* is more than less, grep, etc?
proven text files are more stable, easier to handle, etc.
Please reconsider carefully any foolish action that does not support text files.
Comment 25 Ian Collier 2016-01-05 06:47:31 EST
This is a potential DoS issue.  GNOME apps can log as much garbage as they like, and this all goes into the system journal in the /var partition.  Result: /var is full and essential system messages get missed.

User-level messages should not be going in the system journal.
Comment 26 Fedora End Of Life 2016-07-19 15:26:42 EDT
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 27 udo 2017-10-28 07:36:36 EDT
A possible `solution` AKA workaround:

# cat /etc/rsyslog.d/drop-user-messages.conf 
:syslogtag,contains,"yum"       stop
:syslogtag,contains,"cupsd"       stop
user.* -/var/log/user.log
& stop

# cat /etc/logrotate.d/user-rsyslog 
/var/log/user
{
    missingok
    sharedscripts
    postrotate
        /usr/bin/systemctl kill -s HUP rsyslog.service >/dev/null 2>&1 || true
    endscript
}

This makes all 'user' category stuff (except yum and cupsd output) end up in /var/log/user.log *only* and rotates that extra user log as well.
Comment 28 udo 2017-10-28 07:40:21 EDT
Next thos this, of course, we need systemd.log_level=warning in /etc/extlinux.conf (or somewhere in your grub.conf etc) as well as crond in some mrtg-like situations instead of a systemd timer to reduce the unnecessary logging.
Not every change is progress.

Note You need to log in before you can comment on or make changes to this bug.