明日7月1日、うるう秒が挿入される 37
ストーリー by hylom
出社したら炎上、という事態は嫌ですね 部門より
出社したら炎上、という事態は嫌ですね 部門より
あるAnonymous Coward 曰く、
以前にも報じられているが、明日7月1日の午前8時59分にうるう秒「午前8時59分60秒」が挿入される（ITmedia）。
前回のうるう秒時には自分の周辺にもトラブルに巻き込まれた人はいたが（過去記事）、今回は果たしてどうなるか。
騒ぎ過ぎ (スコア:1)
Y2kの時もそうだったが、みんな騒ぎ過ぎ。
何か月も前からプロジェクトチーム作って対策を検討するとか時間の無駄。
システムの運用にたずさわってりゃいろんな問題が年に何十件何百件と起きる。運悪くトラブったところで、それがひとつ増えるだけのこと。
ま、そんなこと言うと怒り出す人が多いから黙って見てるけど。
Re: (スコア:0)
まったく気にして無かったけど社内のサービスが9時を境にしてダウンしたので、バカにはできない。
Re: (スコア:0)
でも「社内のサービスがダウン」することだって時々あるでしょ?
閏秒対応に時間使うよりも、他の原因でのダウンが
また起きないようにするほうが有効な時間の使い方なんじゃないかな。
Re: (スコア:0)
その「他の原因」+1を防ぐことが今回の対応なのよ。だから有効な時間。
ましてお金をいただいてサービスを提供している方々にとっては死活問題。
Re: (スコア:0)
Y2Kもだけど既知だし、時刻自体元々いい加減な部分あるんだから、最初から対応しとけばいい。
見積もりで金くれたとこは済み。
出さないとこ？契約時に書くからぬかりなし。
炎上 (スコア:0)
不具合が起きたからって火事になるシステムというのもすごいな。
何が起こるかわからないと言えばそうだけど。
うるう秒じゃなくても (スコア:0)
結果、他のマシンと1秒違ったことと等価なのだから
これでトラブル起こすなら、早晩いずれトラブルを起こすんじゃないの?
というか、そういう事象があり得るのは当然想定すべきだし
していないのは怠慢。つーか、まぬけ。
Re: (スコア:0)
> 結果、他のマシンと1秒違ったことと等価なのだから
うるう秒で発生するトラブルはそういう単純な事象と等価ではないのでは？
Re: (スコア:0)
他のマシンと時刻が違うから問題が起きるのではありません。
「サーバー自身が信じている現在時刻」と「正しい時刻」との差が
突然発生してしまうのが問題なのです。
2012年の時は、
「サーバーの時計を1秒調整して正しい時刻に直す」時の
Linuxの時刻合わせ機能がバグっていために、
各地で問題が多発することになりました。
Re: (スコア:0)
× 「サーバー自身が信じている現在時刻」と「正しい時刻」との差が
○ 「サーバー自身が信じている現在時刻」と「それまでサーバーが認識していた現在時刻」との差が
ですね。
うるう秒を挿入しなければならないという状況がサーバーに対して示された瞬間に、
「サーバー自身が信じている現在時刻」はうるう秒の挿入された時刻となり、
「それまでサーバーが認識していた現在時刻」は間違った物と判断されて時刻認識を修正しようとする。
Re: (スコア:0)
よくわからんのだけど、前回のトラブルはどう考えてもLinux（の特定のバージョン）の間抜けなバグが悪いようにしかみえないんだけど。
PCのクロックなんてそもそもたいして正確じゃないし、ntpなんてまさに正確でないことを前提としたサービスなわけで、
うるう秒のせいにするのは責任転嫁にしか見えない。
実際Windows系サーバでは無問題だったんでしょ？
Re: (スコア:0, 参考になる)
まぬけなバグが原因で結論づけるなら、それで終了です。傍観者はそれでいいと思います。
お金を頂くシステム運用は、まぬけなバグにどう対処するのかが求められます。
Re: (スコア:0)
見方としてはそれでいいんじゃない。
責任の所在を探し出し、血祭りにあげて満足すれば良いのであればそれでよい。
ただ実際はバグかないことが保証されたプログラムなど無いし、その中でいかにして支障なく業務を継続できるかが問題なので、建設的なコメントではないね。責任の追及と原因の究明を混同している人にありがちな論理展開。
Re: (スコア:0)
うるう秒って面倒くさいんだよ。
うるう年とかと違って、計算して知ることができないから。
Unixtimeは、1970/01/01 00:00:00からの経過秒数をカウントしているけど、うるう秒は計算して挿入することができないんだ。
うるう秒はいつ挿入されるか前もって決まってないから。
だからうるう秒があるときには別に記録しておかないといけない。
ただ時計が1秒ずれるのとは違うわけ。
怠慢とか、まぬけとか思うなら、どうやってUNIX系のコンピュータがうるう秒を調整しているか自分で調べてみてね。
Re: (スコア:0)
問題は、どうやって1秒を補正するかが、環境によってまちまちであることです。
代表的な方法としては、「8時59分60秒が挿入される」、「8時59分が2回ある」、「徐々に感覚が長くなって元に戻るので挿入はない」などがあります。
また、ややこしい方法としては、「9時00分00秒になってしばらく経った後に、8時59分60秒に逆行する」などもあります。
そして、どの方法を取るかはntpのバージョンによっても違いますし、OSによっても異なります（Linuxではディストリビューションによっても異なります）。
これを全部把握してプログラム側で対応しておけというのは、なかなか大変だと思います。
Re:うるう秒じゃなくても (スコア:1)
×「8時59分が2回ある」→○「8時59分59秒が2回ある」
×「9時00分00秒になってしばらく経った後に、8時59分60秒に逆行する」→○「9時00分00秒になってしばらく経った後に、8時59分59秒に逆行する」
間違いだらけでした。ごめんなさい。
Re:うるう秒じゃなくても (スコア:5, おもしろおかしい)
Re:うるう秒じゃなくても (スコア:1)
うるう"秒"と言われるので、ついつい考える粒度も秒になり、
『60秒という単位（？）に対応していないなら、単に59秒を2秒間維持すればぁ？』
くらいに軽く思ってしまう。
けどパソコンは余裕でミリ秒マイクロ秒単位で動くから、
59.000秒 -> 59.999 -> 59.000 -> 59.999 みたいな推移をして、
前後関係がひっちゃかめっちゃかになって死ぬ。
ミリ秒マイクロ秒の世界だから秒単位でおかしくなるって、
どエラいことなんだぞ、と以前に教えてもらいました。
いちばん近いところで (スコア:0)
ミリ秒単位でとってるセキュアLogの、各行の前後関係なんて
なんか、いい加減なソートやってるところはばらばらになるかも
Re: (スコア:0)
もう一つ。
×「徐々に感覚が長くなって元に戻るので挿入はない」→○「徐々に間隔が長くなって元に戻るので挿入はない」
利用者から見れば、「感覚」でもいいのか。
Re: (スコア:0)
>問題は、どうやって1秒を補正するかが、環境によってまちまちであることです。
>どの方法を取るかはntpのバージョンによっても違いますし、OSによっても異なります（Linuxではディストリビューションによっても異なります）。
だったら、標準規格を作れば良いんじゃないの？ntpだってプロトコルなんだし。規格を作ればすぐに解決する訳ではないけど
このままだと永遠に続くし。規格を作れば、OSやntp、各種ソフトウェアのバージョンアップで徐々に浸透して行くだろう。
「時間」ってのは長さの単位でもあるけど、「時刻」ってのは元々は太陽との位置関係を表したものでしょ？
だったら、閏秒は廃止して日時計の指す時刻と幾ら乖離しようと放ったらかしにするって訳にはいかんと思うのよ。
(何万年後か何億年後か知らんけど、午前9時に日没とかになったら嫌でしょ？廃止は駄目だと思う)
Re: (スコア:0)
30秒ぐらいまとめて変更してくれないかな
太陽と1秒ずれるごとに修正かけるんじゃなく
Re:うるう秒じゃなくても (スコア:1)
そうですね。
19年に7回閏月を入れてみたり…
Re: (スコア:0)
どういうこと？
閏年って丸1年増えるんじゃなくて1日しか増えないんだから、
1秒増えるのはほんとは閏秒じゃない気がする。閏日とか……。
Re:うるう秒じゃなくても (スコア:1)
閏月の挿入される年を閏年と呼ぶ天保暦(旧暦; 太陰太陽暦)
の話題ですね。
閏日がほぼ4年に一度挿入されるグレゴリウス暦の話ではない。
閏秒が挿入される日をも閏日と呼ぶことを提唱していらっしゃる
ようですが、個人的には馴染めません。
Re: (スコア:0)
いったりきたりするUTCを勝手に「絶対的な時刻」と考えて基準にするから悪いのであって
TAIをOSで管理する時刻の基準にし、
人間に表示するときだけUTCなりJSTなりに変換すれば
いいのではないでしょうか。
Re: (スコア:0)
D.J.Bernstenはさすが、TAIしかログに残さないようになってる。１秒単位で挿入するんじゃなくて、毎日１ミリ秒づつ挿入するとか、どうなんだろ？やっぱり面倒かな。
Re: (スコア:0)
「60秒」ってのが存在しないシステムってそこそこ有りそうだけど。
逆に全く対応できないのであれば「何故か1秒進んだ」程度の問題だけど、コンピューターみたいにシステム的に対応しているものとしていない物が連携して動くものでは…
イギリス&ロシアvs.その他？ (スコア:0)
イギリスとロシアがうるう秒を残したい派だそうです。
お気楽管理者の対応例 (スコア:0)
今までシコシコ調査・対応していたんですが、
1.NTPが"-x"で起動してもSLEWモード動作しないパッケージ
2.カーネルのアップデート[禁止|できない]
の[両方|片方]だったりなので、安直にNTPサービスを止めました。
明日出勤したらNTP起動ということで。
実は明日、午後出勤シフトなんですよねー。
どうなることやら…。
Re: (スコア:0)
1.NTPが"-x"で起動してもSLEWモード動作しないパッケージ
これ [vinelinux.org]ですね。
今日寝れない人もいるのかな？ [ryukoku.ac.jp]
Re: (スコア:0)
いい判断だと思いますよ。運用上問題なければ、お手軽かつ確実だと思います。
Re: (スコア:0)
そこまでやっても /usr/share/zoneinfo/right/Asia/Tokyo 使ってたりしたらどうなってたんだっけ？
Re: (スコア:0)
#2839653ですが先ほど全機器のNTP起動が終わりました。
無駄と知りつつ"-x"でSLEWモード稼働にしておいた機器で、
NTP起動 && ntpq -pしたところdelayが0.000でした。
これは機器のクロックズレが無かったと見るか、
それともやはりバグありNTPパッケージのせいと見るか…。
個人的な感想ですが3年前にもあったはずなのにNTPに
バグが残っていたのが意外でした。
RedHatは下記で対応していたようですが、当方CentOSでして。
https://rhn.redhat.com/errata/RHBA- [redhat.com]
Re: (スコア:0)
すみません。#2839635でした。
UTC止めよう(今更) (スコア:0)
time leapもなく、time pointとdurationが単純に換算できる国際原子時を使おう！！！
有効活用していきたい (スコア:0)
1秒あればいつもできないことが出来るようになってうれしい