SSH経由でdateコマンドを実行すると、タイムゾーンが異なります。SSHを使用してサーバーにログインした場合と、同じコマンドを実行した場合は、まったく異なります。
SSHでコマンドを実行する
>ssh root@server 'date'
[root@server]# date
Mon Sep 22 03:06:33 EDT 2014
SSHでログインした後にコマンドを実行します。
[root@server ~]# date
Mon Sep 22 00:07:28 PDT 2014
[root@server ~]#
2番目のケースのタイムゾーンは正しいです。
UNIXでは、環境変数TZを設定することにより、個々のプロセスのタイムゾーンを設定できます。各プロセスはTZに対して異なる値を持つことができるため、異なるタイムゾーンを表示できます。 TZが設定されていない場合は、システム全体のデフォルトがあります。
2番目の例では、リモートサーバーで実行するコマンドを指定してsshを実行しました。したがって、sshは通常の対話型セッションをセットアップし、リモートシステム上のシェルは対話型セッションに対して行うすべての初期化を実行しました。
最初の例(ssh root@server 'date'
)では、リモートホストで特定のコマンドを実行するようにsshに指示しました。この場合、sshはTTYなしでコマンドを実行しました。リモートセッションにTTYがない場合、シェルのリモートインスタンスは、インタラクティブセッションで通常行うすべての初期化を実行しません。そのため、.profile
やシステム全体のプロファイルなどの一部のファイルの調達をスキップしました。
シェルの初期化ファイルの1つが、TZを米国太平洋時間帯の1つに設定しているようです。システムにインタラクティブにログインすると、この初期化が行われ、PDTに時間が表示されます。非対話的にログインすると、この手順はスキップされ、別のタイムゾーンが表示されます。
コマンドを非対話的に実行するときにタイムゾーンを設定できます。
ssh user@Host 'TZ=US/Pacific date'
または、sshにTTYを割り当てるように強制することもできます。これにより、リモートシェルで追加の初期化が実行されます。
ssh -t user@Host 'date'
しかし、本当にすべきことは、シェル初期化ファイルを修正することです。タイムゾーンを毎回設定する場合は、インタラクティブセッションだけでなく、TZを毎回実行するように設定するコマンドを移動する必要があります。
間違ったTZは、おそらく.profile
、.bash_profile
、またはbashrc
を介して設定されているため、/etc/timezone
のマシン全体のTZ設定が上書きされます。