Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 29 Apr 2015 13:41:36 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-bugs@FreeBSD.org
Subject:   [Bug 199767] getty compile error with DEBUG flag
Message-ID:  <bug-199767-8-N8hoMK5h4G@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-199767-8@https.bugs.freebsd.org/bugzilla/>
References:  <bug-199767-8@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199767

--- Comment #3 from Alexandre Fenyo <fbsd.bugzilla@fenyo.net> ---
>> 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,

-- 
You are receiving this mail because:
You are the assignee for the bug.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-199767-8-N8hoMK5h4G>