なんだか懐かしい方々の日記が更新されてるのを見てたまには書くか、と。

イベント的には、
・嫁さんフルタイム勤務に復帰(少し予定外)
　本当は娘が小学校に上がるまでパートで体慣らししようということで
　8月辺りからパートを再開したのですが「資格持ちが非介護職とな？」
　ということになり介護職に復帰、そのまま新営業所のスタート人員として
　フルタイムという流れに。そんなわけでこちらも「働き方改革」どころ
　ではなく分担して休みをとって子供の面倒を見る形に。

　さすがにフルタイム二人いると家計は楽になりますね。
　税金きついけど。

・娘さんインフルA発病
　ということで今週は完全に「出社まかりならん」となり
　ほぼワンオペ看護＋家事。在宅作業で申請したけど全然仕事できない。

・・・・ということでとりあえず生きております。

ボジョレー…。そういえばお店にあったなあ。

今週末は、妻のお母さんが遊びに来て地元の温泉ホテルで飲み食いしてきます。
地元民でも意外に行かない地元の高原ホテル。楽しみです。

ついこの間発表されたiPhoneXSやXS Maxには目もくれずに
iPhnoe8に機種変したアカウントがこちらになります。

昨日機種変対象端末が手元に届き、無事に機種変前のiPhoneSEからの
データ移行が完了したところですが、その翌朝通勤中のバスでSEを落っことして
しまいガラスカバーに盛大な日々をいれてしまって微妙に凹んでいます。

なんだか4桁UIDな皆様の日記は生存確認日記になってるような。
（自分も含めてw）

表のこの件
「Windows搭載の一部PCで時計が1時間早まる不具合が発生。MSが修正を発表するも原因は非公表」

弊社内でもドメイン構成でtime.windows.comを参照していたWindows10 PC 8台中2台で発生した。
別のドメインで上位をntp.nict.jpにしていたマシンたちには発症しなかった。

MSは「修正した。4/4未明には解消した」と言っていることからも、WindowsのOS側コードの
問題ではなさそう。夏時間フラグでも勝手にONになってしまった？という説もあるが、
当のMSが何とも言ってくれないのでわからない。

以前のうるう秒の時に書いた
「LinuxとntpのslewモードとLeapIndicatorビット」
https://srad.jp/~marusa/journal/593599/
の続編

今回のうるう秒は2017年1月1日 08:59:60秒(JST)

以前のうるう秒の時は社内サーバの同期元(上位)NTPサーバがntpdだったのでntpdをslewモードに切り替えて動作させるという対応を行った。
今回は上位NTPサーバがCentOS7のchronydに変わったため、他の方法はないのか調べた結果をまとめておきます。
なおこのサーバはntp.nict.jpと直接同期しており、このサーバに対して社内のntpクライアントが時刻同期を行う構成。

結論から言うと、CentOS7の最新のchrony(2.1.1)ならleap smearモードで動作できるのでそのような設定を行うということ。
Google Public NTPはLeap Smearを採用している

/etc/chrony.confの末尾に以下の設定を追加してchronydを再起動する。

※注意
CentOS7の初期版Chronyはバージョンが低い(1.3だっけ？)ためにleapsecmodeに対応しない。
yum update chronyにて最新版にしておくこと。

# vi /etc/chrony.conf
---
leapsecmode slew
maxslewrate 1000
smoothtime 400 0.001 leaponly
---

# systemctl restart chronyd
# journalctl |grep chronyd
12月 28 11:08:29 sv01 chronyd[12690]: chronyd exiting
12月 28 11:08:29 sv01 chronyd[12870]: chronyd version 2.1.1 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +DEBUG +ASYNCDNS +IPV6 +SECHASH)
12月 28 11:08:29 sv01 chronyd[12870]: Frequency -14.001 +/- 0.007 ppm read from /var/lib/chrony/drift
12月 28 11:08:33 sv01 chronyd[12870]: Selected source 133.243.238.164
12月 28 11:08:33 sv01 chronyd[12870]: Time smoothing activated (leap seconds only)

---
この設定は、chrony本家のchrony.conf (5) manページのleapsecmodeの項に記載されている。

「CentOS7 うるう秒対策 chrony」なんかでググって出てくるQiitaの記事
「Chronyのうるう秒対策」 に書かれている設定はこれが元ネタだと思う。書かれている説明がどうにも微妙なので元ネタを探してしまいましたよ。

https://chrony.tuxfamily.org/doc/2.4/chrony.conf.html
に書かれている原文での説明は以下の通り。

A recommended configuration to enable a server leap smear is:

leapsecmode slew
maxslewrate 1000
smoothtime 400 0.001 leaponly

The first directive is necessary to disable the clock step which would reset the smoothing process. The second directive limits the slewing rate of the local clock to 1000 ppm, which improves the stability of the smoothing process when the local correction starts and ends. The third directive enables the server time smoothing process. It will start when the clock gets to 00:00:00 UTC and it will take 17 hours 34 minutes to finish. The frequency offset will be changing by 0.001 ppm per second and will reach a maximum of 31.623 ppm. The leaponly option makes the duration of the leap smear constant and allows the clients to safely synchronise with multiple identically configured leap smearing servers.

このLeap Smear設定では、17時間34分かけて1秒を吸収している。
GoogleのLeap Smearでは20時間1秒を20時間に刻んでいるそうである。
またAWSのマネジメントコンソールやバックエンドシステムでは、前日12:00:00から毎秒1/86400秒ずつ時計を遅らせ23:59:59に0.5秒遅れ。うるう秒挿入時には0.5秒進みとなり、そこから引き続き毎秒1/86400秒ずつ時計を遅らせて12:00:00に標準時と同期する(24時間かけて1秒時計を遅らせる)という動作になるそうだ。

■参考リンクたち
「うるう秒がやってくる」
http://qiita.com/pitan/items/1cb3f78dd936afc6aa32

「Linuxのうるう秒おさらい」
http://d.hatena.ne.jp/nekoruri/20150629/leapsecond2

「Chronyがうるう秒をどう処理するのか実験してみました」
http://qiita.com/kirksencho/items/f789af7ed6046278b9d3

「Chronyのうるう秒対策」
http://qiita.com/ynishimura0922/items/ab4fed24f680aa034f82

「leap-sec&chronyd」
http://qiita.com/h-imaoka/items/5ac853a34a03218bf552

「chrony.conf(5) Manual Page」
https://chrony.tuxfamily.org/doc/2.4/chrony.conf.html

「Google Public NTP - Leap Smear」
https://developers.google.com/time/smear

AWS調整時刻(AWS Adjusted Time)
http://aws.typepad.com/aws_japan/2015/05/look-before-you-leap-the-coming-leap-second-and-aws.html

「平成29年 (2017年) 1月1日に挿入されるうるう秒について」
https://www.miraclelinux.com/support/axs7/axs7-support/20161101

iPhoneSEの店頭在庫が復活しつつあるとのうわさを聞いて、先日の土曜日に
auショップへ行ってみた。

iPhoneSE 64GBは、ローズゴールドとスペースグレイの在庫。
シルバーとゴールドは在庫なしとのことだった。
今までずっとフロントパネルがホワイトのモデル(iPhoneSEでいうとシルバー)を
使ってきたけれど、まあ別にこだわりもないのでスペースグレイへ機種変更。

元がiPhone5sなので色以外の外観はなにも変わらず。
触った感じも特に変わった点を感じられず。

少し急いだのは、今月で前回機種変更時に始まった誰でも割
(という名の端末代金補助値引き)が終わってしまうためだったので、
これからまた2年間誰でも割継続ということで。

端末を下取りした金額は今までは端末代金から差し引かれていた
（…よな、たしか）が、au WALLETへのポイント入金という
形になりiPhone5sの64GBだと24000ポイントになった。

ここから毎月の請求金額に充てるためにはau WALLET上で操作が必要。

12000ポイントを料金に充てる手続きをすると、毎月2000ポイントづつ
料金支払いにあてられ6か月間有効になる。これを設定した。
240000ポイントあるので、同じことを半年後にすれば、2000ポイントの
12か月間で24000円分の値引きになる。

このほかには6000ポイントコースと3000ポイントコースがあって、
どちらも期間は半年。毎月の金額が1000円か500円かの違い。

まあ個人的には、何の問題もなく端末代金分割払いで契約できたことが
一番のビッグニュースですが。

内閣府　食品安全委員会がFacebookのエントリで反論しています。

「「ｒｅｄ　ｍｅａｔ」と加工肉に関するＩＡＲＣの発表について」
https://www.facebook.com/cao.fscj/?fref=nf

リンクが直リンクじゃないんだけど…

念のため全コピペ
「「ｒｅｄ　ｍｅａｔ」と加工肉に関するＩＡＲＣの発表について
ＩＡＲＣ（国際がん研究機関）は、２６日、加工肉を「ヒトに対して発がん性がある」、
ｒｅｄ　ｍｅａｔを「ヒトに対しておそらく発がん性がある」に分類すると発表しましたが、この情報の見方には注意が必要です。
ヒトの健康に影響を及ぼす可能性のあるものをハザードといいます。一方、ヒトに対する食品の有害影響の度合を定量的に評価することをリスク評価といい、わが国では食品安全委員会、ＥＵではＥＦＳＡ（欧州食品安全機関）、ＢｆＲ（ドイツ連邦リスク評価研究所）、ＡＮＳＥＳ（フランス食品環境労働衛生安全庁）、ＦＳＡ（英国食品基準庁）などで行っており、国際機関としては、ＦＡＯとＷＨＯが合同で運営するＪＭＰＲ（ＷＨＯ／ＦＡＯ合同残留農薬専門家会議）、ＪＥＣＦＡ（ＷＨＯ／ＦＡＯ合同食品添加物専門家会議）などでリスク評価を行っています。リスクは、ハザードの毒性影響の大きさにヒトへのばく露量（食べる量）を考慮して評価します。
ＩＡＲＣ（国際がん研究機関）は、発がん物質のハザードとしての特性を中心に解析を行っている機関であり、物質の発がん性について「グループ１：ヒトに対して発がん性がある」「グループ２Ａ：ヒトに対しておそらく発がん性がある」「グループ２Ｂ：ヒトに対して発がん性がある可能性がある」「グループ３：ヒトに対する発がん性について分類できない」「グループ４：ヒトに対しておそらく発がん性はない」に分類を行っています。この分類は、発がん性を示す根拠があるかどうかを重視しており、したがってハザードの毒性影響の強さやばく露量が及ぼす影響（定量的な評価）はあまり考慮されていません。
リスク評価では、職業（作業）ばく露と食品経由摂取では濃度レベルに大きな違いがあるため、健康への影響を別個に評価しますが、ＩＡＲＣのハザード解析では、物質ごとに、影響が、職業ばく露と食品経由摂取が区別されずにまとめて評価されています。
今回の評価では、これをもって、すなわち「食肉や加工肉はリスクが高い」と捉えることは適切ではないと考えます。食品のヒトの健康への影響については、前述のようなリスク評価機関におけるリスク評価を待たなければなりません。
なお、今回の発表（詳細は公表されていませんので、今後公表される内容を検討することが必要です。）は疫学データに基づいていますが、一般に、疫学データを分析する際には交絡要因（様々な関連する要因）を考慮することが必要となり、容易に結論が出せるものではありません。
食品のリスク評価は、その物質の代謝、毒性試験（短期の急性毒性、長期の慢性毒性、生殖発生毒性、遺伝毒性、発がん性などの試験）、ばく露評価など、十分なデータに基づいて予見を持たずに行われることが必要です。
食品の安全性に関する様々な情報が発信されています。そして、健康な食生活を送っていくためには、それらの情報の正確さや食生活への影響の大きさを見分けるのは難しいことです。それらに振り回されず、多くの種類の食品をバランスの良く食べることが大切です。食品安全委員会では、今後とも科学的で正確な情報を迅速にお届けし、国民の皆様が健康な食生活ができるよう努めて参りたいと考えています。
（一部報道で「ｒｅｄ　ｍｅａｔ」の和訳を赤身肉としていますが、「ｒｅｄ　ｍｅａｔ」 は、牛肉、豚肉、羊肉などを指し、日本語でいう霜降り肉の対義語の赤身肉は「ｌｅａｎ　ｍｅａｔ」です。）
」

前回2012年のうるう秒挿入ではLinuxカーネルの不具合でカーネルがパニックしたり
CPUを100%消費したりといった問題が一部で起きました。
http://www.sakura.ad.jp/news/sakurainfo/newsentry.php?id=655

今年も同じことが起こらないように調査と対策を実施中です。
うちでは、後ほど記載する3案のうち対策2を実施しました。
(ntpdをSLEWモードに切り替える。)

まずLinuxカーネル側の状況について。

RHEL/CentOSでは、CentOS5はカーネルが古く問題の不具合が存在していない。
CentOS7では対策済みのカーネルになっている。CentOS6の場合はすこし微妙で
RHEL/CentOS6.3までは不具合のあるカーネルが存在する。
RHEL/CentOS6.4では修正済みカーネルになっている。

http://www.rack.sh/linux-leap-second/
＞(一部が修正) : RHEL/CentOS6.3 : kernel-2.6.32-279.5.2.el6
＞(完全な修正) : RHEL/CentOS6.4 : kernel-2.6.32-358.el6

バグの引き金はNTPのLIビットで、LI（LeapIndicator）がオンであり
かつうるう秒が挿入されていない状態にあるとき、カーネルパニック
を引き起こすバグがある。

またうるう秒が挿入されたときに、そのことをLinuxカーネルに通知しない
バグがありそのためにfutexに起因する負荷上昇が起きる。

メカ二ズムの詳細は下記
http://ringeye.jawfish.org/~ori/misc/leapsecond-20120701.html

対策としては以下の通り。

対策1：対策済みカーネルにバージョンアップする
kernel-2.6.32-358.el6以上にすればOK。
ただしミッションクリティカルなサーバでカーネルのバージョンアップ
そのものが不可能だったり、カーネルバージョンアップ後の再起動が
できない環境もあるので、その場合は対策2で逃げる。

対策2：ntpdを最新にバージョンアップしたうえで、ntpdを
STEPモードからSLEWモードに切り替える。

手順としてはこんな感じ
1. ntp のバージョンアップ
# yum update ntp

2. ntpdを停止する
# service ntpd stop

3. kernelの保持時刻・周波数オフセットをクリアする
# ntptime -s 0 -f 0

4. ntpdをslewモードで起動するようセット
# vi /etc/sysconfig/ntpd
- OPTIONS="u ntp:ntp -p /var/run/ntpd.pid -g"
+ OPTIONS="-x -u ntp:ntp -p /var/run/ntpd.pid -g"
  -xオプションを追記して保存

5. ntpd を起動
# service ntpd start

この場合、カーネルは相変わらずLIビットが立ったままの時にカーネルパニック
を起こす問題が残っているはずで、対策になってない可能性がありましたが、
ntpdがSLEWモードで動作しているときにはLIビットがONにならず、また
8:59:60もカウントされないので問題ないようです。

http://hiroki.jp/leap-second-2015
＞またSLEWモードで起動しているとうるう秒を挿入しなくなります。
＞(後述するLeap Indicatorがセットされない)

ただしここで注意が必要なのが、ntpパッケージのバージョンです。
ntp-4.2.6p5-3.el6_6未満のバージョンでは、-xを付けても正しく
動作しないバグがありました。最新のntpdに更新しておく必要が
あります。
https://rhn.redhat.com/errata/RHBA-2015-0690.html

うるう秒をカウントしない分、9:00:00の時点ではサーバの時計が1秒進むことに
なりますがntpdが再度上位と同期して時刻が進んでいることを検知すると毎秒
0.5msずつ時計を遅らせて最終的には正しい時刻になります。

(別解)
ntpdのバージョンアップや設定変更などはサーバの数が少ない環境ならば
現実的ですが、何千台もある環境ではやってらんないことになります。
問題なのはntpで伝達されるLIビットなので、これが伝わらないようにすればいい
ということで、組織内のntpサーバの上にもう一つ問題修正済みのカーネルと
最新のntpdをインストールしたntpサーバを用意し、ここでLIビットを落として
しまうという解が提示されています。

http://qiita.com/kirksencho/items/a4f8aa64e1ec2aca2af7

新たに建てる上位ntpdでは、スタンドアロンモードにしてクライアントを
受け付けないようにし、別のntpd実装であるchronyを使ってLIビットなしの
ntpサービスを提供するのが肝のようです。

ページ内のどこでもいいから、モバイル版URLへのリンクを
どこか分かりやすいところに置いて欲しい。

老眼気味の目にスマホでPC版ページはキツイ。