[Date Prev] [Date Index] [Date Next] [Thread Prev] [Thread Index] [Thread Next]

Re: CRLF logging

Bryan Stansell bryan@conserver.com
Fri, 26 Mar 2004 06:14:44 -0800 (PST)

On Fri, Mar 26, 2004 at 02:49:34PM +0100, Michael Redinger wrote:
> when testing conserver I found that the logfiles contain CRLF, LF and CR
> line terminators.
> Most lines are ended with CRLF (but I also saw lines with only LF).
> Also, there is often a CR right after the timestamp.
> See the example below (note the "^M"s).

that's pretty wild.  not surprising, really, but interesting.  the
characters spit out by various pcs when booting is fun to see.

> Who is to blame, conserver or the Linux server system?

the server.  unless there's a bug, conserver "blindly" takes all the
data it gets from the console and writes it to the log file.  if it
weren't for the timestamping, it would be a byte-for-byte replica of
everything it receives.  since you have timestamping, the extra info is
also written.  the only interpretation conserver is doing in your case
is looking for a LF, so it can insert the timestamp.  but, again, any
binary data, CR, etc is coming from the console.

> I remember seeing something like this in Cyclades TS logs, so I suppose
> it is not very unusual.


> Is there any way to prevent this?

not from withing conserver.  if conserver were to just strip all CR
characters, it might drop things that are actually important.  if it
weren't for the 7-bit mode (-7 option), i'd say that all the data is
always left exactly as it was recieved (with the exception of inserts
like timestamp).  the 7-bit mode is probably useless these days (and if
you're seeing bad high-bit data, you've probably got a low-level serial
configuration issue) and i'd like to get rid of it so i can say that
conserver always logs exactly what it sees coming from the console 100%
of the time.  that's a basic philosophy i'd like to maintain (hence my
desire to drop the -7 stuff).

does any of that help?