How to get syslog to log in GMT or any other time zone
James Harris
over the recent time change
Mar 29 00:58:01
Mar 29 00:59:01
Mar 29 02:00:01
Mar 29 02:00:25
Each line is followed by the server name and the log entry. Notably,
there's no indication of how the timezone changed.
Presumably this would be worse when the clocks change the other way in
that multiple entries would have the same time stamp.
I cannot find any way to change how sysklogd gets or formats its time.
Fixing logs to use GMT would be ideal.
Any ideas how to change the time zone in the logs? If relevant, this
is Ubuntu.
James
jellybean stonerfish
Perhaps you could edit /etc/timezone and make your default system
time gmt. Then change the timezone of each user to the local time.
Michael Black
Set up two cron jobs, so one logs a message saying something like
"Daylight Savings starts now" and the other "Daylight Savings ends now".
Michael
James Harris
Thanks for the replies. I think I have a fix. In case anyone else
wants to do the same thing here is the solution.
I noticed (largely by guesswork) that the system date command takes
notice of a TZ environment variable.
$ echo $TZ
$ date
Wed Apr 1 11:15:58 BST 2009
$ export TZ=UTC
$ date
Wed Apr 1 10:16:16 UTC 2009
$
It turns out syslogd also honours the variable though this seems to be
undocumented. Anyway /etc/init.d/sysklogd contains this line
test ! -r /etc/default/syslogd || . /etc/default/syslogd
which picks up environment variables from the included file so I added
TZ=UTC to /etc/default/syslogd and restarted the daemon with
sudo /etc/init.d/sysklogd restart
Now the entries in syslog and other logs have the GMT time stamp.
Hopefully this should mean they remain stable when the clocks next
change.
James
James Harris
...
> which picks up environment variables from the included file so I added
> TZ=UTC to /etc/default/syslogd and restarted the daemon
A small additional note: I found that TZ=UTC didn't work on another
machine. TZ=GMT, though, was fine and seems to work on both machines.
James
J.O. Aho
I would guess the other machine has an old glibc installed, when UTC wasn't
introduced.
Be careful, so that your GMT isn't just a renamed WET.
--
//Aho
Moe Trin
<9e5b9ad2-623b-4073...@l10g2000vba.googlegroups.com>,
James Harris wrote:
NOTE: Posting from groups.google.com (or some web-forums) dramatically
reduces the chance of your post being seen. Find a real news server.
> James Harris <james.harri...@googlemail.com> wrote:
>> which picks up environment variables from the included file so I
>> added TZ=UTC to /etc/default/syslogd and restarted the daemon
>A small additional note: I found that TZ=UTC didn't work on another
>machine. TZ=GMT, though, was fine and seems to work on both machines.
Depends on how your timezone data was compiled. Using the "standard"
continental source files (africa, antarctica, asia, australasia,
europe, northamerica and southamerica) in the tzdata2009d.tar.gz
file, there is neither a UTC or GMT zone defined. To have such
zonefile, you need to compile the 'etcetera' source file as well.
(There are 414 zone files and 15 directories in /usr/share/zoneinfo
from the 7 continental source files - the 'etcetera' file would add
an /usr/share/zoneinfo/GMT zonefile, and /usr/share/zoneinfo/Etc/
directory that adds 35 zonefiles including /usr/share/zoneinfo/Etc/UTC
and /usr/share/zoneinfo/Etc/GMT. You may have a 'tzset' man page
which describes the syntax for the TZ variable:
[compton ~]$ whatis tzset
tzset (3) - initialize time conversion information
[compton ~]$
If TZ appears in the environment but its value is a null
string, Coordinated Universal Time (UTC) is used (without leap sec-
ond correction).
(Older versions of the tzset library call also defaulted to UTC if the
value was not recognized as a zoneinfo filename.)
That leap-second correction (currently -34 seconds) may or may not be
important to you. If it is, perhaps one of the African timezones
such as Africa/Bissau, Africa/Dakar, or Africa/Abidjan (which are all
on GMT) would be preferable.
Old guy
Moe Trin
<73hls7F...@mid.individual.net>, J.O. Aho wrote:
>James Harris wrote:
>> A small additional note: I found that TZ=UTC didn't work on another
>> machine. TZ=GMT, though, was fine and seems to work on both machines.
>I would guess the other machine has an old glibc installed, when UTC
>wasn't introduced.
HUH???
[compton ~]$ zgrep UTC /net/hubble/old/rpmcontents.[35]* | grep zone
/net/hubble/old/rpmcontents.3.0.3.gz: /usr/lib/zoneinfo/Etc/UTC
/net/hubble/old/rpmcontents.3.0.3.gz: /usr/lib/zoneinfo/UTC
/net/hubble/old/rpmcontents.52.gz:/usr/share/zoneinfo/Etc/UTC
/net/hubble/old/rpmcontents.52.gz:/usr/share/zoneinfo/UTC
/net/hubble/old/rpmcontents.52.gz:/usr/share/zoneinfo/posix/Etc/UTC
/net/hubble/old/rpmcontents.52.gz:/usr/share/zoneinfo/posix/UTC
/net/hubble/old/rpmcontents.52.gz:/usr/share/zoneinfo/right/Etc/UTC
/net/hubble/old/rpmcontents.52.gz:/usr/share/zoneinfo/right/UTC
[compton ~]$
Red Hat 3.0.3 dates from 1996, and used libc5. Red Hat 5.2 dates from
1998 and used glibc2. But note my other reply - UTC (or GMT) isn't
defined in the 'continental' series of source files, even though 17
zonefiles effectively are UTC with no DST. If the distribution
package author decided to compile the tzdata data and included the
'etcetera' source file, in the '/usr/sbin/zic' command line, you'd
have those extra UTC/GMT zones.
>Be careful, so that your GMT isn't just a renamed WET.
If it is, the package author should be shot, because the 'africa' and
'europe' source files (which define zones using the 'WET' string)
plainly indicate (the Rules and RULES keywords) if DST is used.
Old guy