497日後にLinuxのuptimeにてラップアラウンドが発生
※ラップアラウンドとは、処理可能な範囲の最後に達した後に、最初に戻ること
[[BIG-IP]] LTM 10.0.1, 10.0.0, 9.6.1, 9.6.0, 9.4.8, 9.4.7, 9.4.6, 9.4.5, 9.4.4, 9.4.3, 9.4.2, 9.4.1, 9.4.0, 9.3.1, 9.3.0, 9.2.5, 9.2.4, 9.2.3
9.2.2, 9.2.0, 9.1.3, 9.1.2, 9.1.1, 9.1.0, 9.0.5, 9.0.4, 9.0.3, 9.0.2, 9.0.1, 9.0.0
BIG-IP ASM 10.0.1, 10.0.0, 9.4.8, 9.4.7, 9.4.6, 9.4.5, 9.4.4, 9.4.3, 9.4.2, 9.4.1, 9.4.0, 9.3.1, 9.3.0, 9.2.5, 9.2.4, 9.2.3, 9.2.2, 9.2.0
BIG-IP GTM 10.0.1, 10.0.0, 9.4.8, 9.4.7, 9.4.6, 9.4.5, 9.4.4, 9.4.3, 9.4.2, 9.4.1, 9.4.0, 9.3.1, 9.3.0, 9.2.5, 9.2.4, 9.2.3, 9.2.2
BIG-IP PSM 10.0.1, 10.0.0, 9.4.8, 9.4.7, 9.4.6, 9.4.5
BIG-IP Link Controller 10.0.1, 10.0.0, 9.4.8, 9.4.7, 9.4.6, 9.4.5, 9.4.4, 9.4.3, 9.4.2, 9.4.1, 9.4.0, 9.3.1, 9.3.0, 9.2.5, 9.2.4, 9.2.3, 9.2.2
BIG-IP WebAccelerator 10.0.1, 10.0.0, 9.4.8, 9.4.7, 9.4.6, 9.4.5, 9.4.4, 9.4.3, 9.4.2, 9.4.1, 9.4.0
BIG-IP WOM 10.0.1, 10.0.0
FirePass 7.0.0, 6.1.0, 6.0.3, 6.0.2, 6.0.1, 6.0.0, 5.5.2, 5.5.1, 5.5.0, 5.4.2, 5.4.1, 5.4.0, 5.2.2, 5.2.1, 5.2.0, 5.0.0, 5.0 FP1-3
Enterprise Manager 1.8.0, 1.7.0, 1.6.0, 1.4.1, 1.4.0
これは既知の不具合によるものです。
BIG-IPのバージョン9.0.0から10.0.1はLinuxのカーネルバージョン2.4を使っています。
カーネルのuptimeは10ミリ秒または瞬間の単位で起動からの時間を内部でカウントしています。
Linuxバージョン2.4は32bitカウンターで、2^32または4,294,967,296の最大値を持ちます。
カウンターがこの値(497日2時間27分53秒)に達すると0に戻って増加します。
注釈 : 更なる情報はSOL3645: Base operating system information for the BIG-IP Host system.を参照してください。
F5製品開発は、CR74550としてこのLinux問題を追いました。
そして、64bitカウンターを使っているLinuxカーネル2.6を実装している、BIG-IPバージョン10.1.0とEnterprise Managerバージョン2.0で改善されています。
64bitカウンターは0に戻る前に非常に多くカウントすることができます。
更新情報はBIG-IP LTM, ASM, GTM, PSM, Link Controller, WebAccelerator, WOM, Enterprise Managerのリリースノートを参照してください。
この問題はFirePassでまだ影響があります。
カウンターが0に戻るとき、次の副作用を見るかもしれません。
・ps(Process Status)コマンドは、カウンターが0に戻るときに起動していたデーモンのため、TIME値を誤って報告するかもしれません。
・Linuxのuptimeコマンドと他の時間に関係するコマンドは正しい値を報告しないかもしれません。
・以下のSolutionsで詳述されているように、正確に経過時間の計算に依存するいくつかのプロセスは悪影響を受けているかもしれません。
SOL7071: SCCP kernel driver i2c read failure
SOL8087: SCCP kernel driver timer wrap may cause system component health misreadings (FirePass only)
SOL9679: The lacpd daemon stops sending LACP messages after 497 day linux uptime wraparound
SOL9683: The gtmd, tmm, or bcm56xxd daemons may crash after 497 day linux uptime wraparound
[[SOL10311]]: The performance graphs no longer display data after 497 day linux uptime wraparound
注釈 : これらは、uptimeカウンター戻りのみの既知の副作用です。
その中で注意されるように、これらのSolutionsで文書化される問題は修復されました。
関連があるようであるが、ここで文書化されていない問題に遭遇するならば、F5テクニカルサポートに連絡してください。
プラットホームによって、カウンターが0に戻ったかどうかに関わらず、システムuptimeを決定するには異なる手順が必要かもしれません。
Linuxのuptimeコマンドはカウンターがまだ0に戻っていなかったら正しい値を表示します。
しかし、システムが497日以上経過していれば、Linuxのuptimeコマンドはラップアラウンドの影響を受けて、システムの実際のuptimeが表示されません。
システム稼働日数が497日以上であるかどうかは正式に決定します。
システムが起動するときに作られる、/var/log/ksysms.0 ファイルとシステムクロックで報告される日付の差で判断することができます。
/var/log/ksysms.0 ファイルはラップアラウンドの影響を受けません。
システムの稼働日数が497日未満であれば、Linuxのuptimeコマンドを使うことができますが、予防保守の定期的な再起動を計画すべきです。
Linuxのuptimeコマンドは以下の例と似た結果を出力します。
19:52:48 up 20 days, 9:24, 1 user, load average: 0.09, 0.05, 0.11
注釈 : SCCPのプラットフォームでは、SCCPにログインしてuptimeコマンドを実行してください。
プラットフォームがSCCPを使っているかどうかは、SOL9476: The F5 hardware/software compatibility matrix.を参照してください。
しかし、システムが497日以上稼働していたら、Linuxのuptimeコマンドはおそらくラップアラウンドの影響を受けて、システムの実際のuptimeが表示されないかもしれません。
システムの稼働時間が497日を超えていてもいなくても、起動時に作成される/var/log/ksysms.0ファイルのタイムスタンプを確認して決められます。
重要 : システムが497日より長く稼働している、またはシステムがどれくらい稼働しているかわからないときはuptimeコマンドの出力結果に頼らないでください。
その代わりに、システムがどれくらい稼働していたかを決定するために、以下のセクションの手順を参照してください。
SCCPのないシステムでは、次のコマンドを使って起動からの日数を決定します。
# echo $[(`date +%s` - `ls -l --time-style +%s /var/log/ksyms.0 | awk '{print $6}'`) / 86400]
コマンドはシステムが起動してからの日数を整数で出力します。
例えば、現在の日付が2009年9月18日 12時14分49で、/var/log/dsysms.0ファイルのタイムスタンプが6月26日 10時54分だとします。
システムは起動してからおよそ84日1時間20分ですが、コマンドの結果は起動してから丸84日を意味する84と出力されます。
SCCPシステムでは次の手順を実行します。
1.SCCPにログインします。
補足 : SCCPにはBIG-IPにログイン後にsshでログインします。
[xxxxxxx@xxxxxxx:Standby] ~ # ssh sccp
Welcome to the F5 Networks SCCP!
sccp#
2.次のコマンドを実行すると、UNIX時間で現在の日時が秒数で表示されます。
※UNIX時間とは、システム上で日時を表す単位で、UTCで1970年1月1日0時0分0秒から経過秒数で表されます。
# date +%s
3.SCCPからログアウトして、TMMコマンドプロンプトに戻ります。
4.次のコマンドを実行すると、UNIX時間で/var/log/ksysms.0ファイルのタイムスタンプが秒数で表示されます。
# ls -l --time-style +%s /var/log/ksyms.0 | awk '{print $6}'
5.最初の値(手順2で出力された秒数)から2番目の値(手順4で出力された秒数)を引くと、システムが稼働している秒数が得られます。
6.システムが稼働している日数を測定するために、結果を86400(1日分の秒数)で割ってください。
注釈 : プラットフォームがSCCPを利用しているかどうかは、SOL9476: The F5 hardware/software compatibility matrix を参照してください。
ラップアラウンドが発生する497日よりも前にシステムを再起動することで、この問題を回避することができます。
1.BIG-IPのコマンドラインにログインします。
2.次のコマンドを実行してシステムを再起動します。
・SCCPのプラットフォーム
BIG-IPのバージョンが9.1.2, 9.1.3, 9.2.4 よりも新しい場合
# full_box_reboot
BIG-IPのバージョンが9.0.0から9.1.1と9.2.0から9.2.3の場合
# touch /.sccp_hard_reboot ; reboot
・他のプラットフォーム
# reboot
注釈 : プラットフォームがSCCPを利用しているかどうかは、SOL9476: The F5 hardware/software compatibility matrix を参照してください。
最終更新：2012年05月31日 21:26
