Bug 985922

How to get the old behaviour of logging in .xsession-errors back?

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.

~/.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.

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.

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.

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.

Same in Fedora 20.
/var/log/messages is garbage.
Will the real cause please be mentioned?
Will the real cause please be fixed?

Any updates? Any info needed? Logs?

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

Any updates?
Any extra info needed?
Any patches I could test?

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

Colin, as the author of the change to GDM, could you comment on any of the above?

How to get the old behaviour of logging in .xsession-errors back?
/var/log/messages was waaaaayyyyyy cleaner back then.

(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

Error 404 - Not Found
The site '/doc/v7-stable' does not exist here.

Why is it so hard to fix this essential unix behaviour?

(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.

(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.

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.

I'm working for an (upstream) patch for X to log natively to the journal.

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

(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?

(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.

(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.

(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.

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.

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.

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.

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.