timestamp in named log is off by one hour

[Rajasekhar Raman]

A very curious thing on our DNS server:

The timestamp is the named.run file is off by exactly one hour. The system time is correct and did adjust correctly for DST.

I cannot seem to figure out where the named process is getting its timestamp from. I don't have any specific loggin directives in the named.conf. Just running named with a debug level of 2, and using the default debug logfile of named.run.

The DNS server is running HP-UX 11.11.

Any answers out there?

[Bill Hassell]

named, like all standard processes, is started by the script /sbin/ioinitrc and /sbin/rc. The way time works on HP-UX is that the system keeps UTC (aka, GMT or Zulu) time. Then the Unix standard libraries translate the UTC time to another timezone using the value of $TZ. The rules defined by the TZ value are found in the file /usr/lib/tztab, or if no rule is found in tztab, the details in the man page for environ will define what TZ will do.

The default TZ value is always found in /etc/TIMEZONE but if missing, then US CST (Central timezone) will be substituted. It's important to understand that you can have many, many timezones on HP-UX at once. This is ideal for a system used in many different locations -- just have the user change the TZ value to match their local location in $HOME/.profile and now date, ll, any command that shows the time will match the local location.

[Dennis Handly]

>The timestamp is the named.run file is off by exactly one hour.

What is the format for this timestamp, does it include the timezone?
If it does, you know how to fix it. If it doesn't, you'll have figure out why TZ is bad as Bill says.

[BUPA IS]

Hello,
A number of processess (especially low level routines loaded soon after boot ) rely on the kernel setting timezone rather than TZ which used for the shells and most tasks. The default is +420 which is 7 hours west of greenwich this value should be agree with your system default TZ settings for normal (winter) time .
Check the kernel value for dst. 1 follows US conventions, 3 western european conventions, 0 turns off dst changes.
You will need to rebuild the kernel and reboot to change these values.
The sam configurable kernel parameters help under miscellaneous for timezone and dst has more detail.

Mike

[Rajasekhar Raman]

Firstly, thanks for the responses. Here are my findings based on the input I have received.

1. the /etc/TIMEZONE file exists and has the following value:
TZ=EST5EDT
export TZ

2. the named process is running under user "named" which has been chrooted. The "named" user itself has no .profile set, so I assume it is getting the TZ value from the systems default profile.

3. The timestamp in the named.run log file does not indicate timezone. A sample line taken at 9:59 am this morning looks like this

Apr 02 08:59:16.514 createfetch: www-google-analytics.l.google.com A

Its exactly an hour off.

[Rajasekhar Raman]

And by the way the kernel value for dst is set to 1.

[BUPA IS]

Hello,

> 2. the named process is running under user "named" which has been chrooted.

I found this link under bind faq you may need an copy of /etc/TIMZONE unde the "new" root directory

http://www.bind9.net/BIND-FAQ
look for
Q:
Why are my logs in GMT (UTC).

Mike

[Rajasekhar Raman]

Thanks for the answers. Looks like there is a copy of the "tztab" file in the chrooted /usr/lib which was still the old file. Despite the DST patch being applied to the system this particular tztab file was not updated.

Copying the /etc/TIMEZONE file did not make a difference as the corresponding "tztab" file was incorrect and the TIMEZONE file is useless without the correct "/usr/lib/tztab" file.

I copied the "/usr/lib/tztab" file to the chrooted /usr/lib and that fixed the issue.

Thanks a lot everyone.

[Rajasekhar Raman]

Copied "/usr/lib/tztab" to the new root and restarted named.