Can you give an example where this could cause troubles? I mean you rarely grep for whitespace patterns :)

(In reply to Michal Sekletar from comment #2)
> Can you give an example where this could cause troubles? I mean you rarely
> grep for whitespace patterns :)

Well, if you log something, whitespace or not, you expect the message to be stored as you've logged it.
Second guessing what the message "should" look like by removing whitespace seems a little arbitrary. Is this the only change done to the messages? Is this documented anywhere?

An example of a serious issue this policy caused is given in rhbz#743890 which this bug blocks.

TL;DR if you want your /var/log/messages on RHEL7 look the same as it did on RHEL5/6 setup syslog forwarding and don't look at data stored by journal at all.

https://github.com/systemd/systemd/issues/98

Sorry.

Fixed upstream for leading whitespaces:
https://github.com/systemd/systemd/pull/156

This is the commit that went in:
https://github.com/systemd/systemd/commit/6f6fdcb5906ff9259443b97daca429ed1de2559c

Tested with `pstree | logger` and confirmed that the journalctl output showed the output as originally formatted by pstree.

Trailing whitespace will still be stripped (but hopefully nobody was actually relying on those being present.)

Cheers,
Filipe

(In reply to Filipe Brandenburger from comment #5)
> Fixed upstream for leading whitespaces:
> https://github.com/systemd/systemd/pull/156

Thanks, this is an improvement.

> Trailing whitespace will still be stripped (but hopefully nobody was
> actually relying on those being present.)

This is still a problem. I don't think hope is a good backwards-compatibility policy.

Devel-ack for backporting https://github.com/systemd/systemd/commit/6f6fdcb5906ff9259443b97daca429ed1de2559c 

I don't think that the other part will be ever acccepted in upstream and we are not going to patch it downstream.

Hi Tomas,

(In reply to Tomas Heinrich from comment #6)
> (In reply to Filipe Brandenburger from comment #5)
> > Trailing whitespace will still be stripped (but hopefully nobody was
> > actually relying on those being present.)
> 
> This is still a problem. I don't think hope is a good
> backwards-compatibility policy.

I guess it really depends on what bug 743890 is requesting (that bug is private, so I can not really check that myself.)

I can see how stripping leading whitespace might be a problem if you're expecting to dump formatted output of commands into logs and stripping whitespace may indeed make it less readable, that's why I fixed the leading whitespace case and tested it using `pstree` which is not too realistic but is something that produces such a formatted output.

I really don't see how removing trailing whitespace will break a *sane* log parser (though I wouldn't be surprised to see it.)

In any case, as pointed out by Lennart in https://github.com/systemd/systemd/issues/98, for such use cases it's always possible to run a regular syslog daemon such as rsyslog and just use ForwardSyslog=yes, in which case the regular syslog should get the original messages verbatim including all the whitespace (I haven't really checked that's the case myself.) So users that have legacy scripts that rely on trailing whitespace should be able to use that workaround, which is likely to always keep working.

Do you think that's acceptable?

https://github.com/lnykryn/systemd-rhel/commit/fa74ba131041161f1ae9fbc0a3b11f9a005b9d8f

(In reply to Filipe Brandenburger from comment #11)
> I can see how stripping leading whitespace might be a problem if you're
> expecting to dump formatted output of commands into logs and stripping
> whitespace may indeed make it less readable,

The core of the issue is not as much a misaligned output as that the message is modified at all.

> that's why I fixed the leading
> whitespace case and tested it using `pstree` which is not too realistic but
> is something that produces such a formatted output.

Yeah, thanks for the patch.
I can't see why retaining leading whitespace is acceptable but trailing whitespace is not, though. (Not that it was your call.)

> I really don't see how removing trailing whitespace will break a *sane* log
> parser (though I wouldn't be surprised to see it.)

I don't think we can afford to assume "sane".
You can have a stupid piece of hw that can't be updated or an ancient piece of closed sw that can't be replaced or a large deployment that would be too costly to fix.
I don't think we should break all these use cases because whitespace "is a menace".

> In any case, as pointed out by Lennart in
> https://github.com/systemd/systemd/issues/98, for such use cases it's always
> possible to run a regular syslog daemon such as rsyslog and just use
> ForwardSyslog=yes, 

That proposal is bogus. With this workaround you loose the benefits of using journald and you get some additional drawbacks.
A unix socket is not a good storage medium. You can resume reading messages from journald after a week - you can't do that with ForwardSyslog. If the messages are coming in too fast, you loose some of them.
Ideally, all consumers would be migrated to one (journald) API. Saying "we don't provide this functionality, use the old interface" seems silly.

> in which case the regular syslog should get the original
> messages verbatim including all the whitespace (I haven't really checked
> that's the case myself.)

I've checked, the messages are not modified.

> So users that have legacy scripts that rely on
> trailing whitespace should be able to use that workaround, which is likely
> to always keep working.
> 
> Do you think that's acceptable?

There don't seem to be any other options right now.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2092.html