Comment 5 for bug 1154207

The description of this bug already mentions a new option (by which I assume Clint means something like 'console timelog' or 'console log --timestamps' ?)

So, that already implies a new variety of console stanza. I personally do not think we should change the current meaning of 'console log' since, as we do not currently support syslog, who knows what sorts of scripts folk have that might be slurping this data and piping it over syslog or filtering the logs with nagios, etc (let's not forget that 'console log' is in an LTS release already).

Adding something like 'console syslog' seems like a good alternative as it is not breaking the existing behaviour. But for another twist, how about 'console kmsg' - that *is* available from early boot and also has the ability to timestamp.

What format would these timestamps take? Would that format be configurable? What time resolution is appropriate? I'd rather leave an existing facility like syslog or the kernel ring buffer to deal with that.

> Reading and looking for newlines to know when
> to add a timestamp is not hard.
Imagine this scenario: a job produces a 300Mb stream of bytes which only contains \n right at the end. That means -- if we want to add timestamps -- that Upstart has to buffer that data until it sees the \n (since it wouldn't make sense to write the timestamp *before* a "line" of data was actually read). This is admittedly a contrived example but it has to be catered for. Currently, that situation should not arise since the data is persisted as soon as possible.