This is a very minor bug. A printf format mismatch in /usr/src/libexec/getty/subr.c breaks compilation in a section of the source code that is only compiled while the DEBUG constant is #defined. Here is the code snippet extracted from subr.c: #ifdef DEBUG printf("name=\"%s\", buf=\"%s\"\r\n", name, buf); for (sp = gettystrs; sp->field; sp++) printf("cgetstr: %s=%s\r\n", sp->field, sp->value); for (np = gettynums; np->field; np++) printf("cgetnum: %s=%d\r\n", np->field, np->value); for (fp = gettyflags; fp->field; fp++) printf("cgetflags: %s='%c' set='%c'\r\n", fp->field, fp->value + '0', fp->set + '0'); #endif /* DEBUG */ Here is the compilation error log: # cd /usr/src/libexec/getty ; touch subr.c ; make DEBUG_FLAGS=-DDEBUG cc -O2 -pipe -DDEBUG -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c /usr/src/libexec/getty/subr.c /usr/src/libexec/getty/subr.c:169:43: error: format specifies type 'int' but the argument has type 'long' [-Werror,-Wformat] printf("cgetnum: %s=%d\r\n", np->field, np->value); ~~ ^~~~~~~~~ %ld 1 error generated. *** Error code 1 Stop. make: stopped in /usr/src/libexec/getty As proposed by cc, the bug is corrected by simply changing this line: printf("cgetnum: %s=%d\r\n", np->field, np->value); by this one: printf("cgetnum: %s=%ld\r\n", np->field, np->value); The bug occurs on every currently supported FreeBSD releases. Sincerely,
Created attachment 156088 [details] Remove DEBUG code.
What for do you use -DDEBUG in getty ? The chunk is probably useless, and seems to be a simple overlook from r15645. The fact that nobody bothered with the issue for 20 years is telling. I intend to remove the #ifdef DEBUG code.
>> What for do you use -DDEBUG in getty ? I've been using -DDEBUG because it helped me finding the root cause of another bug. Here is this other bug, and this one is really annoying: Even if you launch getty with a terminal type (the first parameter of getty) that contains the "nl" capability in the /etc/gettytab terminal configuration database, getty does not set correctly the expected tty output mode (opost | onlcr) with tcsetattr() when it first start and wait for a login name. The opost and onlcr output mode flags are set by getty only after a first newline or linefeed character has been received from the terminal (before that event, onlcr is set but with no effect since opost is not set). The consequence of this bug is that the rsyslogd port does not output logs correctly on /dev/console. Rsyslogd finishes lines to /dev/console with "\n". So, when you have never tried to log-in on the console, for instance after a reboot, rsyslogd sends "\n" at end of lines, which are not post-processed by the tty to "\r\n". Then, you get no carriage return between lines, only a line feed. Once you have logged-in, or simply entered a login, the problem is solved. But if you log-out from the console, it will happen again. This bug happens with every console drivers (vt and sc): they both need CR and LF, so /dev/console must have opost and ocrnl set, to handle correctly the processes that only write "\n" at EOL. I do not see such a problem with the native BSD log daemon (syslogd) when logging on /dev/console, because it explicitely finishes each line by writing "\r\n" to the console. I've not reported this bug in getty because it would need lots of modifications in subr.c and main.c to be patched, since the line mode is handled "by hand" by getty when reading the login (the device is in raw mode during this step: output flag opost is cleared and line-mode processing, like handling backspaces or ^U, is done by getty, not by the console driver: it is hardcoded in the function getname() in main.c ; yes, this is awful!), and the terminal configuration extracted from /etc/gettytab is really used to configure the tty only after having read the login (except for the speed and parity parameters, that getty handles correctly from the beginning). So, I'm planning to provide a patch proposal for the rsyslogd port, instead of providing a patch proposal for getty. Until that time, I will be using the only mean I've discovered to correct this bad behaviour: */5 * * * * /bin/stty opost < /dev/console > /dev/null 2>&1 :-) Sincerely,
(In reply to Alexandre Fenyo from comment #3) I dig the syslogd.c history back to the CSRG, and it seems that very first commit to the syslogd which I found explicitely added '\r' to the end of line on all terminals, including console. I think your finding definitely points to a bug in rsyslogd. I still do not see a usefulness of the #ifdef DEBUG-braced chunk of code. It verifies the parsing of the gettytab db, which was hardly a problem in the last 20 years. I will remove this shortly.
Ok, thanks.
A commit references this bug: Author: kib Date: Wed Apr 29 19:47:19 UTC 2015 New revision: 282245 URL: https://svnweb.freebsd.org/changeset/base/282245 Log: Remove the #ifdef DEBUG code, which is not compilable on 64bit architectures. It seems to be an overlooked chunk in the r15645. PR: 199767 Sponsored by: The FreeBSD Foundation MFC after: 1 week Changes: head/libexec/getty/subr.c
A commit references this bug: Author: kib Date: Wed May 6 09:38:45 UTC 2015 New revision: 282523 URL: https://svnweb.freebsd.org/changeset/base/282523 Log: MFC r282245: Remove the #ifdef DEBUG code, which is not compilable on 64bit architectures. PR: 199767 Changes: _U stable/10/ stable/10/libexec/getty/subr.c
(In reply to Konstantin Belousov from comment #4) For information, I've posted a patch to correct the rsyslog bug we talked about here: bug report 200270.