Bug 200270 - sysutils/rsyslog8, sysutils/rsyslog7, sysutils/rsyslog8-devel, sysutils/rsyslog7-devel: When logging on the console, rsyslog writes "\n" instead of "\r\n". Therefore, console output is made of lines that start at the column where the previous line ended.
Summary: sysutils/rsyslog8, sysutils/rsyslog7, sysutils/rsyslog8-devel, sysutils/rsysl...
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: Brad Davis
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-05-17 16:55 UTC by Alexandre Fenyo
Modified: 2015-09-02 23:35 UTC (History)
0 users

See Also:

Attachments
rsyslog patch to correct this bug (937 bytes, patch)
2015-05-17 16:55 UTC, Alexandre Fenyo 		no flags Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Alexandre Fenyo 2015-05-17 16:55:58 UTC 
Created attachment 156857 [details]
rsyslog patch to correct this bug

The attached patch is written to work correctly for each of the 4 rsyslog ports: sysutils/rsyslog8, sysutils/rsyslog7, sysutils/rsyslog8-devel, sysutils/rsyslog7-devel

When logging on the console, rsyslog writes "\n" (NL) instead of "\r\n" (CRNL). Therefore, console output is made of lines that do not start at the first column.

This bug in rsyslog is linked to the bug report 199767 about getty and has been confirmed by Konstantin Belousov on comment 4: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199767#c4

One may think it is not necessary to patch rsyslog since it could be possible to automatically convert any "\n" char that rsyslog writes to the console to "\r\n", simply setting the opost and onlcr output mode flags on the console (using /etc/gettytab).

But for some tricky reasons that are explained in bug report 199767, it is not possible for those flags to be set at any time, specifically because of this getty behaviour: when getty is waiting for a login, it clears the opost flag to handle the line-mode by itself (the terminal device is in raw mode during this step, the output flag opost is cleared and line-mode processing, like handling backspaces or ^U, is done by getty, not by the terminal driver).

So, rsyslog must be patched because it can not work correctly on a console attached to getty.

the corresponding patch is attached to this bug report. It must be added to the files directory of each rsyslog port.
Comment 1 Brad Davis freebsd_committer freebsd_triage 2015-05-18 14:11:25 UTC 
Have you submitted this patch upstream as well?
Comment 2 Brad Davis freebsd_committer freebsd_triage 2015-05-18 14:12:28 UTC 
Oh, nevermind.. I see the post to rsyslog list now.
Comment 3 Alexandre Fenyo 2015-05-18 14:52:04 UTC 
Yes, I obtained a response from G. Rainer, the upstream major contributor and author of rsyslog, after having simultaneously submitted the patch to FreeBSD bugzilla and rsyslog distribution list.

As you have probably read, G. Rainer prefers not to include the patch in the mainstream distribution since the correct expected behaviour on FreeBSD could be handled by applying a specific template for console logging.

So, I mainly see two ways to close this report:

1- add a message at the end of "sysutils/rsyslog8/files/pkg-message.in" explaining what for and how to add a specific template to get correct console output

2- apply this patch

Personally, I would prefer the latter way, for 3 main reasons:
a- it needs no specific work for the user
b- many users forget do not take care reading pkg-message files
c- it allows to import a previously written configuration file from another operating system to FreeBSD without any modification

Anyway, the patch may not be included in the mainstream, since G. Rainer prefers to exclude any risk of potential regression, "given the fact how many functions are using the patched code and those do not need this special handling in general".
There is currently a discussion about this on the rsyslog mailing list.

I've taken care to write and intensively test this 10-lines patch, so I'm confident everything would be ok, but a regression is always possible, with such a big (and nice) software.

Sincerely,
Comment 4 Alexandre Fenyo 2015-05-18 15:18:33 UTC 
A piece of thoughts about the pros and cons:

- if getty on FreeBSD would fully comply with the /etc/gettytab parameters, a simple modification in /etc/gettytab could let rsyslog and the FreeBSD console drivers work correctly together. But this would need to change a 30 years old code, so we could encounter regressions on getty (this is more or less the conclusion of the bug report 199767).

- if rsyslog, only when compiled on FreeBSD (the patch makes use of "#ifdef __FreeBSD__"), would directly send "\r\n" to any console, it would comply with the behaviour expected by the FreeBSD console drivers. But someone could encounter regressions on rsyslog (on FreeBSD only).

So, it is a balance between a regression in getty and a regression in rsyslog. Both regressions could only happen on FreeBSD.

But even if getty would be modified, /etc/gettytab would need a change to make rsyslog work correctly without the need to add templates in the rsyslog configuration file).

On the contrary, applying the patch to rsyslog is the *only* way that let the user do nothing to get rsyslog work correctly on a FreeBSD console.

So, I would prefer the patch to be applied, for instance in the FreeBSD ports tree in case the main stream really wants to avoid any risk of regression.

Sincerely
Comment 5 Alexandre Fenyo 2015-05-24 18:37:52 UTC 
Hi,

I've not seen any response from Rainer to your proposal on the rsyslog mailing list, for a week. Since I've read many other responses from Rainer about other subjects, I'm afraid that he will not want to include the patch on the main stream.

=> Do you think we should continue to wait for a response from Rainer for the patch to be included upstream, or could we simply include the patch in the FreeBSD ports tree ?

For information, since this current bug report is not closed, and since I've found another bug in the same source file on rsyslogd, I've posted another bug report (200429) with a patch named "patch-runtime_stream.c2" instead of "patch-runtime_stream.c" to avoid overlapping names between this bug report and the new one.

Many thanks,
Sincerely,
Comment 6 commit-hook freebsd_committer freebsd_triage 2015-05-28 15:44:24 UTC 
A commit references this bug:

Author: brd
Date: Thu May 28 15:44:04 UTC 2015
New revision: 387739
URL: https://svnweb.freebsd.org/changeset/ports/387739

Log:
  Update sysutils/rsyslog8 to 8.10.0

  Include a few bug fixes:
  1) Endless loop at boot time
  2) Console output starting on the previous line

  PR:		200429 [1]
  PR:		200270 [2]
  Submitted by:	Alexandre Fenyo <fbsd.bugzilla@fenyo.net> [1 and 2]
  Approved by:	bdrewery (mentor)

Changes:
  head/sysutils/rsyslog8/Makefile
  head/sysutils/rsyslog8/distinfo
  head/sysutils/rsyslog8/files/patch-plugins_imfile_imfile.c
  head/sysutils/rsyslog8/files/patch-runtime_stream.c
Comment 7 Alexandre Fenyo 2015-05-28 15:55:10 UTC 
Many thanks for the commit
Comment 8 Alexandre Fenyo 2015-09-02 23:35:26 UTC 
I think the status should be set to Close/FIXED.
Can you change it to this value ?
Thanks,