Timezone discrepancies

[Jonathan McKee]

We have two HP servers, which we run tabs on via scripts run from a third remote machine, but I have recently discovered a very strange behaviour:

serverX@root#: rsh pumbaa "uname -a;echo \"TZ=$TZ\";/usr/sbin/kmtune | grep timezone; /usr/sbin/kmtune | grep \"dst \";date"
HP-UX pumbaa B.11.11 U 9000/800 620309382 unlimited-user license
TZ=MET-1METDST,M3.5.0/02:00:00,M10.5.0/03:00:00
timezone 420 - 420
dst 1 - 1
Wed Sep 20 08:00:47 METDST 2006

So far all well. But on the other server:

serverX@root#: rsh bamse "uname -a;echo \"TZ=$TZ\";/usr/sbin/kmtune | grep timezone; /usr/sbin/kmtune | grep \"dst \";date"
HP-UX bamse B.11.11 U 9000/800 629309372 unlimited-user license
TZ=MET-1METDST,M3.5.0/02:00:00,M10.5.0/03:00:00
timezone 420 - 420
dst 1 - 1
Wed Sep 20 02:01:17 EDT 2006

I've checked /etc/default/tz and /etc/TIMEZONE on both servers, and they are identical. I've even checked the "locale" and they are identical.

I can't see why the second server Bamse is reporting the date in EDT and only when queried remotely.

[Jean-Yves Picard]

Hello,

have you compared
remsh pumbaa env
whith
remsh bamse env
?

Jean-Yves

[Andres Viir]

Yes, I compared the two "env":

serverX@root#bin: remsh pumbaa "env"
_=/usr/bin/env
PATH=/usr/bin:/usr/ccs/bin:/usr/bin/X11:/usr/contrib/bin:/usr/local/bin:
LOGNAME=root
SHELL=/sbin/sh
HOME=/
PWD=/
TZ=MET-1METDST


serverX@root#bin: remsh bamse "env"
_=/usr/bin/env
PATH=/usr/bin:/usr/ccs/bin:/usr/bin/X11:/usr/contrib/bin:/usr/local/bin:
LOGNAME=root
SHELL=/sbin/sh
HOME=/
PWD=/
TZ=EST5EDT


Although the HP servers are identical in root's .profile, /etc/profile, and csh.login, as well as /etc/TIMEZONE, /etc/default/tz, and the kernel parameters "dst" and "timezone".

[Bill Hassell]

A couple of things:

- Change your query for timezone and dst to a single grep:

/usr/sbin/kmtune | grep -e timezone -e \"dst \"

for efficiency. Note that the kernel parameters timezone and dst are virtually meaningless today. A long time ago, some programs would not use the standard Unix library calls for ctime (and friends) and would have to make a crude approximation of the time from the timezone value and the dst setting. The dst value is particularly crude and will produce wrong offsets for many different timezones.

- Your TZ value is carrying a rule from your info-gathering machine which may not apply the same way on your HP-UX boxes. The long form:

TZ=MET-1METDST,M3.5.0/02:00:00,M10.5.0/03:00:00

It should work but I would first try this command directly on each HP-UX box:

TZ=MET-1METDST,M3.5.0/02:00:00,M10.5.0/03:00:00 date

Also check the contents of:

cat /etec/TIMEZONE
cat /etc/default/tz

From the man page for timezone:

"if TZ is not present, then the value contained in /etc/default/tz is used for the default...if /etc/default/tz is not set then the default value is equivalent to EST5EDT (Eastern Standard Time) of the USA."

[Peter Nikitka]

Hi,

the problem is your remsh/rsh call:

serverX@root#: rsh bamse "uname -a;echo \"TZ=$TZ\""

The value of $TZ is expanded by the local shell of 'serverX' and not at the remote host 'bamse'.
You'll have to use something like this:
rsh bamse 'uname -a;echo TZ=$TZ'

Call 'set -x' in your shell before the 'rsh' call or use
TZ=UUU-9VVV rsh bamse "uname -a;echo \"TZ=$TZ\""
to verify this.

mfG Peter

[Jonathan McKee]

Thanks to everyone for their clarifications so far.

The problem is this:

Two servers, bamse and pumbaa are, as far as I can see, identical, with regards to their timezone settings.

pumbaa#: cat /etc/default/tz
EST5EDT

bamse#: cat /etc/default/tz
EST5EDT

pumbaa#: echo $TZ
MET-1METDST

bamse#: echo $TZ
MET-1METDST

pumbaa#: cat /etc/TIMEZONE
TZ=MET-1METDST
export TZ

bamse#: cat /etc/TIMEZONE
TZ=MET-1METDST
export TZ

Neither set any timezone parameters in root's .profile.

Both source /etc/TIMEZONE in /etc/profile.

Both have the same "dst" and "timezone" kernel parameters, as shown in the original post.

The question is: On bamse, when the date command is run via remsh/rsh/ssh, why is it giving the time in EDT, and not METDST?

Or, put another way: Why does pumbaa respond to:

serverX@root#: rsh pumbaa 'date'

with the expected timezone, and bamse does not?

What other parameters are there that could be causing this issue? When I send the command to pumba, what exactly is happening? Somehow, it seems to be picking up the correct timezone, yet bamse fails to fo this, and may be defaulting to /etc/default/tz.

[Peter Nikitka]

Hi,

what happens, if you put
MET-1METDST
into /etc/default/tz ?

mfG Peter

[Bill Hassell]

I would simplify your rsh query. As mentioned, your local shell will expand variables like $TZ before sending the result to your remote systems. To avoid this, start with a simple query:

rsh pumbaa 'echo $TZ;date'
rsh bamse 'echo $TZ;date'

In this case, you are not sending TZ (as defined in your local computer) but are asking what the current environment has. If you do this:

rsh pumbaa "TZ=$TZ date"
rsh bmase "TZ=$TZ date"

You are taking $TZ from serverX and sending it over to the remote systems. To see what thye shell does to your command line, do this:

echo rsh pumbaa "TZ=$TZ date"
echo rsh bmase "TZ=$TZ date"
echo rsh pumbaa 'TZ=$TZ date'
echo rsh bmase 'TZ=$TZ date'

NOTE: rsh (remsh inside HP-UX) has a limited environment just like cron or at. Try this to see the environments:

rsh pumbaa env
rsh bamse env

[Jonathan McKee]

Peter:
Tried changing the value in /etc/default/tz but I got no change in the behaviour, on either machine. Would the change require a reboot?

[Jonathan McKee]

Bill:

Yep I tried that:

serverX@root#: rsh pumbaa "env"
_=/usr/bin/env
PATH=/usr/bin:/usr/ccs/bin:/usr/bin/X11:/usr/contrib/bin:/usr/local/bin:
LOGNAME=root
SHELL=/sbin/sh
HOME=/
PWD=/
TZ=MET-1METDST

serverXroot#: rsh bamse "env"
_=/usr/bin/env
PATH=/usr/bin:/usr/ccs/bin:/usr/bin/X11:/usr/contrib/bin:/usr/local/bin:
LOGNAME=root
SHELL=/sbin/sh
HOME=/
PWD=/
TZ=EST5EDT

Why is this so, when the two servers are otherwise equal, as far as I have been able to ascertain?

Why does bamse set TZ to EST5DST, even when /etc/default/tz is changed? Why isn't pumbaa showing the same behaviour? Pumbaa isn't defaulting to /etc/default/tz. Why not?

[Bill Hassell]

This is sounding like a startup problem where inetd has inherited the default TZ value from /etc/rc.config, the script that sources all the files in /etc/rc.config.d/*. There is also a script /sbin/rc which sets the default TZ value. This default value should have been overridden by the rc.config script at bootup.

So check /etc/TIMEZONE to see that it sources correctly on bamse:

. /etc/TIMEZONE

The key is that if TZ is not set, the value of /etc/default/tz is used. TZ would not be set if the /etc/TIMEZONE file could not be sourced. Also check the tz file for readability. The man page for ctime gives the precendence information.

However, if inetd inherited TZ=EST5EDT then all networking daemons run by inetd will have that TZ value, thus pointing to a bootup problem in the /sbin scripts.

[Peter Nikitka]

Hi,

to verify this, you could check against sshd (if configured):
- check first, if the symtoms are the same in rlogin and ssh connections
- if ssh is OK, you should scan the daemon startup(s) at boottime, like Bill suggested.

- restart one service of sshd or inetd
- check again

Check additionally for messages in rc.log.

mfG Peter