[syslog-ng] Timestamp inconsistency

[Evan Rempel]

In your log snippet, it appears that it is sshd that is logging with the
"wrong" timezone. This is a bug in some versions of sshd. Upgrading sshd
may fix the specific problem you are having.

I can not comment on the behavior of the timezone handling in syslog-ng.

Evan Rempel

Tim Boyer wrote:
> I'm running 2.0.0, and the docs say that
> 
>    The sender can specify the timezone of the messages. If the incoming
>    message includes a timezone it is associated with the message. Otherwise,
>    the local timezone is assumed.
> 
> I'm not specifying any timezone, but I'm seeing a bunch of messages stamped
> UTC mixed in with EDT, which makes the log a bit... weird:
> 
> Jun 24 21:38:01 tolstoy.denmantire.com sshd[7949]: Connection closed by
> 192.168
> Jun 24 17:40:01 tolstoy.denmantire.com crond[7987]: (root) CMD
> (/usr/lib/sa/sa1
> Jun 24 21:43:01 tolstoy.denmantire.com sshd[7994]: Connection closed by
> 192.168
> Jun 24 17:44:34 tolstoy.denmantire.com syslog-ng[11618]: Log statistics;
> droppe
> Jun 24 21:48:02 tolstoy.denmantire.com sshd[8036]: Connection closed by
> 192.168
> Jun 24 17:50:01 tolstoy.denmantire.com crond[8082]: (root) CMD
> (/usr/lib/sa/sa1
> Jun 24 21:53:03 tolstoy.denmantire.com sshd[8107]: Connection closed by
> 192.168
> 
> So just to test, I did this:
> 
> TZ="UTC+23:56" logger "Look I'm logging from yesterday"
> 
> and sure enough, it logged it as yesterday.
> 
> So I tried to explicitly set the time zones:
> 
> options {
>   send_time_zone(-04:00);
>   recv_time_zone(-04:00);
> 
> destination dtolstoy_all {
>   file("/var/log/tolstoy.log" owner(root) group(hobbit) perm(0640)
> time_zone(-04:00));
> 
> Restarted syslog-ng, and:
> 
> Jun 24 17:09:00 tolstoy.denmantire.com syslog-ng: syslog-ng startup
> succeeded
> Jun 23 21:13:09 tolstoy.denmantire.com tim: Look I'm logging from yesterday
> 
> I don't understand why it's not logging as local time without me having to
> do anything.  And I _really_ don't understand why the explicit instructions
> don't work.
> 
> Pounters in the the right direction appreciated...
> 
>