William (or Colin as I suspect this is related to systemd), can you help this user? Is it a bug or an expected change after migration to Mageia 5, requiring configuration changes?

CC: (none) => mageia, warrendiogenese

Firstly, does "journalctl -u postfix" show you such log messages?

not, since systemd journal is disabled.
systemd's journal was not very handy, took long to get simple log entries & uses too much diskspace, so i decided in Mageia 4 to completely disable journal & reanabled rsyslog to write simple human-readable files

I reenabled journalctl:
entries for dovecot & postfix get logged, but since they are different untis, you can't get a log of both together.
In systemd I don't see how to show the logging target, "tail -f", backup logs, have different log-sizes for processes,...

that is why I don't want to use journalctl - and I think there are many more good reasons.

(In reply to M K from comment #4)
> I reenabled journalctl:
> entries for dovecot & postfix get logged, but since they are different
> untis, you can't get a log of both together.

Yes you can:

  journalctl -u postfix -u dovecot

> In systemd I don't see how to show the logging target, "tail -f", backup
> logs, have different log-sizes for processes,...

Not sure what you mean by "logging target"? If you mean the syslog facility, you can access this via:

  journalctl _SYSLOG_FACILITY=2

If you mean the syslog identifier, then you can use

  journalctl _SYSLOG_IDENTIFIER=postfix/pickup

tail -f is (perhaps unsurprisingly) journalctl -f.

There is no concept of backup logs. There is just an overall size limit for all logs and an individual journal size. Everything is automatically rotated when needed. Compression is built in and the full index is always available without having to spend time decompressing and grepping.

> that is why I don't want to use journalctl - and I think there are many more
> good reasons.

For what it's worth, here is an article I read recently that doesn't specifically talk about journal logs but is relevent and you may find it interesting:

https://asylum.madhouse-project.org/blog/2015/05/05/grepping-logs-is-terrible/

Keep in mind that the journal is meant to be useful for the majority of people for the general use cases. Having recently had to fight with an old server without journal I can tell you that going back to the old ways is really hard once you get used to the features!

Ultimately it's your choice and I won't try and "convert" you, but can you confirm whether on not the journal sees those logs when rsyslog does not?

If it does, can you attach the output from "journalctl -u postfix -u dovecot -o verbose"?

Also if the output does exist, does installing the "rsyslog-journald" (and restarting rsyslog) restore the logging to files too?

Also FWIW, the journal cannot be disabled per-se (it's an essential part of system startup), but it can be configured to not log to disk and to only keep a very small amount in ram. I presume this is what you mean when you did when you said "journal is disabled" above?

I'll read that article later - thanks.

rsyslog-journald did the first trick - was it changed since mga4? shouldn't rsyslog have a dependecy on that package?

by disabling, I meant, setting "Storage=none":
'"none" turns off all storage, all log data received will be dropped. Forwarding to other targets, such as the console, the kernel log buffer or a syslog daemon will still work however.'

CORRECTION:
rsyslog logging only works, if Storage is NOT none, volatile is ok. But as you can read from the man page (cite above) Storage=none should work with other syslog daemons as well.

(In reply to M K from comment #6)
> I'll read that article later - thanks.

No problem.

> rsyslog-journald did the first trick - was it changed since mga4? shouldn't
> rsyslog have a dependecy on that package?

It probably should IMO. I didn't do the rsyslog packaging so I'd be tempted to suggest it should just be merged into the main package and always included. If you install rsyslog, you pretty much want this.

It did change yeah.

In systemd 216 (from the NEWS file FYI):

        * journald will no longer forward all local data to another
          running syslog daemon. This change has been made because
          rsyslog (which appears to be the most commonly used syslog
          implementation these days) no longer makes use of this, and
          instead pulls the data out of the journal on its own. Since
          forwarding the messages to a non-existent syslog server is
          more expensive than we assumed we have now turned this
          off. If you run a syslog server that is not a recent rsyslog
          version, you have to turn this option on again
          (ForwardToSyslog= in journald.conf).

So I would say that the rsyslog packaging is not really ideal and we should fix it.

> by disabling, I meant, setting "Storage=none":
> '"none" turns off all storage, all log data received will be dropped.
> Forwarding to other targets, such as the console, the kernel log buffer or a
> syslog daemon will still work however.'
> 
> CORRECTION:
> rsyslog logging only works, if Storage is NOT none, volatile is ok. But as
> you can read from the man page (cite above) Storage=none should work with
> other syslog daemons as well.

Yeah, so FowardToSyslog= would still work with storage=none, but as rsyslog doesn't use this and instead "pulls" from journal I guess you need Storage=volatile to allow rsyslog to get it.

The man page is technically not wrong, but it's certainly misleading considering how rsyslog works. I'll prep a patch to add some extra details to the man page that mentioned how rsyslog is typically setup to clarify this.

Does this all make sense?

Assigning the bug report to rsyslog maintainer, based on the recent comments.

Assignee: bugsquad => warrendiogenese
Summary: Not logging any mail events => Not logging any mail events (rsyslog needs fixing since upstream systemd changes)

@all: thanks for your help so far!

https://bugs.mageia.org/show_bug.cgi?id=16634#c4

There is indeed a bug affecting the upgrade 4->5, otherwise any install of rsyslog and syslog-ng takes care of this already.

The fix is uninstall rsyslog and reinstall it.

PS: Just forget to set a case for $1 -eq 2

*** This bug has been marked as a duplicate of bug 16634 ***

Status: NEW => RESOLVED
CC: (none) => dirteat
Resolution: (none) => DUPLICATE

To Colin:
In fact, I don't understand why this has happened, there is an unconditional:

%post
%{_sbindir}/rsyslog_switchfwd %{journalcfgdir} on

that apparently is ignored during distro upgrade? Is that expected?