ただつらつらと日記が書かれていくようです。

投稿者: 管理人 (1ページ目 (39ページ中))

さくらインターネットのNTPサーバ「ntp1.sakura.ad.jp」ってleap smearしてたのか。

うるう秒は避けられないとしても、それをいかにしておおごとにしないかはなかなか重要なことな気がする。まぁ、そういう観点ではleap smearすることによってなんとかするのも1つではあるけれど、やっかいなことにleap smearしないNTPサーバとleap smearするサーバを混ぜて参照するのは止めた方がよさそうだ(まぁ、普通に混乱するだろうな)

…だがしかし、publicなNTPサーバのうち、leap smearしてるかどうかを明記してるNTPサーバってそんなに数多くない気がする。まぁ、書いてなきゃleap smearしてないんだなくらいの理解でもいいんだろうけれど。

たまたま、さくらインターネットのなかのひとが書いた記事(うるう秒がやってくる)を眺めていたら、こんな記事が書いてあった。

さくらインターネットのお客様向けに提供している ntp1.sakura.ad.jpでは、leap smearを採用し、時間をかけてゆるやかに時刻補正する仕組みを採用しています。

お、そうなのか。さくらインターネットのntp1.sakura.ad.jpはleap smearしてたのか。なるほど。国内のパブリックNTPサーバでleap smearしているサーバってそんなに多くない(まぁ、有名どころのnictやインターネットマルチフィードあたりのNTPサーバは対応してなさそうな雰囲気だし)ような気がするので貴重かも。あ、でも、さくらインターネットのネットワーク外からの参照ができないんだっけ(うろ覚え)

むむむ。

ThinkCentre M720q(Coffee Lake)にRocky Linux8.6をインストールしたら時計がズレまくった。

中古で買ってきたThinkCentre M720q TinyにRocky Linux8.6をインストールした。搭載しているCPUはCore i5-8500Tなので、第8世代のCore i5であり、開発時のコードネームはCoffee Lake。

インストール自体はすんなり終わったけど、よく見てると、まぁ、時計がズレまくっている。timedatectlコマンドの結果を確認してみると、NTPで調整してみても、結果的にRTC time(リアルタイムクロック)の時刻がすさまじい勢いで進んでしまうので、chronydが同期をあきらめてしまうようなレベルでズレていた。

時計がズレるという事象で思いついたのが、マザーボード上のCMOS電池、CR2032の電力が無くなっているのかなと思いついて、CR2032電池を交換してみたがなにも解消しない。まぁ、なんとなくハマった実感はあったのでいろいろと調べてみるとこの記事を見つけた。

Linux Kernel Disables Coffee Lakes HPET On The Grounds That It Is “Unreliable”

この記事によると、Linuxが利用できるClocksource(時間を計測するための情報源?例えば、1秒の経過を正確に把握するための情報源ってところだおるか)にはいくつかあって、CPUを情報源とするTSC(Time Stamp Counter)や、マザーボード上のチップを情報源とするHPET(High Precision Event Timer)、ACPIを情報源とするACPI-PM(ACPI Power Management Timer)などがあるみたいんだけど、Coffee LakeとIce Lakeの世代のHPETはぶっ壊れているらしく、PCが低電力状態に状態になった時にLinuxカーネルのClocksourceの監視機構で問題が起きるらしい。

こんなエラーメッセージが出るとして紹介されているメッセージ(確かに似たようなのが、ウチのThinkCentre M720q Tinyでも出てた)はこんな感じで、壊れているのはHEPTなのにTSCが壊れているようなメッセージになっていてややこしい。

clocksource: timekeeping watchdog on CPU7: Marking clocksource ‘tsc’ as unstable because the skew is too large:
clocksource: ‘hpet’ wd_now: 54b0f25 wd_last: 4e9fe44 mask: ffffffff
clocksource: ‘tsc’ cs_now: 3e0e2debe0 cs_last: 3daab92440 mask: ffffffffffffffff
tsc: Marking TSC unstable due to clocksource watchdog
TSC found unstable after boot, most likely due to broken BIOS. Use ‘tsc=unstable’.
sched_clock: Marking unstable (4024083039, -219)<-(4075977403, -51894628) clocksource: Switched to clocksource hpet

この問題、2019年11月にLinusさんがコミットしたパッチで回避されているらしいけど、Rocky Linux8.6のカーネルには未反映なんだろうか。

とりあえず、ワークアラウンドとして、/etc/default/grubに書かれている起動時のカーネルオプションにHEPTを無効化するnoheptを追加して、それを反映させて再起動することが挙げられていた。うちのThinkCentre M720qでも同じことをやってみたら時計のズレが収まった…とりあえず、めでたしめでたし。

参考:

Amazon Linux 2022がなかなかGAにならないと思ったら、Amazon Linux2のEOLが延長された。

Amazon Linux2022のことが発表されて、しばらくプレビュー版のまま。なかなかGAにならないなぁと思ってはいたけれど、もう7月。2022年の半分が終わってしまったことになる。いっそ、Amazon Linux2023くらいにしておいた方がよかったんじゃないかなぁーと無邪気に思ってたら、Amazon Linux2のEOLが延期されてた。延長されたEOLは2024年6月30日。

そっと、Amazon Linux2のFAQページが更新されてるのが興味深い。

AmazonLinux2のEOLが2024年6月30日に1年間延長

AmazonLinux2のEOLが2024年6月30日に1年間延長

PHP8.0を動かすインスタンスを構築しようと思っていて、Amazon Linux2022を待っていたけれど、結局、PHP8.0のEOLが2023年11月26日なのでPHP8.0のEOLの方がAmazon Linux2よりも早くEOLを迎えることになるので、まぁ、なかなかGAにならないAmazon Linux2022を待つよりもAmazon Linux2で構築しちゃおうか。

さくらのクラウドのディスクのクローンで「待機中」

さくらのクラウドで、サーバーをクローンするためにディスクをクローンしようとしているけど、「待機中」のステータスになって、いっこうにディスクのコピーが進捗するする気配がない。ディスクのコピーは常にインスタンスからアクセスされているストレージ(SANだったっけ)のリソース(帯域幅やCPU)をがっつり使うことになるので、コピーの優先度を上げるわけにはいかないだろう。例えば、複数のユーザーからのディスクコピーのリクエストがパラレルに走らないような制御がなされているんだろうけど…。

例えば、ヤバい!って事態に陥って、急遽、サーバをクローンしようとしてこの状況に直面すると切ないだろうな…と思いながら、まったく進まないプログレスバーを眺めてみたりして。

しかし、AWSだとこういう待ち時間がなかったような気がするんだけどなぁ。インスタンスを起動するときにはAMIの裏側のS3からEBSにがっつりデータをコピーしているはずだし、サーバのクローンをする時にもEBSとS3の間でゴリゴリとデータをコピーしているはずだけど、特にちょっと待ってってステータスになっているのは見たことがない気がする。まぁ、さくらのクラウドがショボいというか、むしろ、AWSのEBS周りのネットワークの帯域幅はどれだけ太いんだって話かもしれないけど。

UQ mobileのデータ高速プランを解約してみた。

以前に契約して中途半端にしか使っていなかったUQ mobileのデータ高速プランを解約することにした。

まぁ、データ高速プランはUQ mobileがMVNOっぽいSIMの売り方をしていた時の料金プランで、UQ mobileがKDDIにおけるY!モバイルっぽい立ち位置に移行してからは新規申込みを止めたプラン。今は音声契約が必須になっているので、まぁ、MNOの契約であるにも関わらず、データ専用で(SMSは付いてるけど)3GBで990円というプランは今となっては珍しいと言えるかもしれない。

いざ解約するべく調べてみたら、UQ mobileの解約はコールセンターへの電話のみという…まぁ、今時、なんだかなぁという印象。例えば、Webサイト屋auショップでも解約を受けてくれればいいのに、解約の窓口が電話しか用意しないことで解約のハードルを上げるっていうのはなかなかイケてない気がするけどな。

そして、UQ mobileのWebサイトには「必ず、契約者ご本人さまが、解約をするスマートフォン/携帯電話本体から、電話番号の前に186を付けるなどの方法で携帯電話番号を通知してお電話ください。」と書かれていたが、データ専用プランなので音声の発信ができない。データ通信専用のデータ高速プランなんて忘れられているんだろうな…。いやはや、音声通話できるドコモのSIMが入ったスマホから電話した。

というわけで、UQ mobileのコールセンターに電話したのは日曜日の13時ちょっと前。自動音声応答システムでメニューを選択する方式だった。そして、解約する電話番号と暗証番号を電話機のダイヤルパッドから入力。その後が長かった。オペレーターさんに電話がつながるまでに保留された時間がざっと30分。途中で、このまま待つか、かけ直すような案内もなされるが、休日なんてずっと混み合ってるんだろうし、コールセンターへの電話しか解約窓口を用意してぐったりするくらい保留されて解約を断念してしまったら、解約のハードルを上げてなんとかしようとするKDDIの思うつぼだし。

30分くらい保留音を聞き続けてオペレーターさんにつながった後は早かった。解約にあたっての注意事項が告げられて、それを確認して終了。MVNOなんかはWebで解約を受けてるわけだし、Webでも実現できるとしか思えないやりとりであった。総務省や公正取引委員会はこういうあたりもチェックすべきだと思うんだけどなぁ…。

MySQL5.7をyumでアップデートしようとしたらコケた

CentOS7が動いているサーバにMySQL5.7をOracleのレポジトリからyumでrpmを取得する形でインストールしてあったのだが、そのサーバでyum updateをかけたら、yumがエラーで止まった。

The GPG keys listed for the “MySQL 5.7 Community Server” repository are already installed but they are not correct for this package.
Check that the correct key URLs are configured for this repository.

…GPGが何やらおかしいとのこと。で、調べてみると、以前よりOracleのレポジトリで使っていたPGPキー、CentOS7だと/etc/pki/rpm-gpg/RPM-GPG-KEY-mysqlに置かれることになる、この鍵は有効期限が2022年2月16日までだったそうで、新しい鍵に切り替えられたらしい。

そんなわけで、古い鍵ではアップデートが出来なくなったようだ。だったら、新しい鍵をインポートしちゃえばいいってことで。

sudo rpm –import https://repo.mysql.com/RPM-GPG-KEY-mysql-2022

を実行すれば、今のレポジトリで使われている鍵がインポートされるので、yumのアップデートが普通に実行されるとのこと。

ただまぁ、前から2022年2月までの有効期限だったはずだけど、極めて最近になって発覚して、急遽、GPG鍵が新しいものになったようで…。

参考:
The MySQL GPG key seems to be incorrect
https://bugs.mysql.com/bug.php?id=106188

Changes in MySQL 8.0.28 (2022-01-18, General Availability)
https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-28.html#mysqld-8-0-28-packaging

Kindle Paperwhite(第11世代)がフリーズ。。。

Kindle Paperwhite(第11世代)を購入して使っている。いまのところ、Kindle本は大丈夫そうではあるるが、夜間飛行のメルマガをKindleで読もうとするとページめくりができなくなってフリーズしてしまい、後は強制的にリセットするしかないようだ。うーむ。

一応、Kindle Paperwhite(第11世代)をフリーズさせるメルマガを、かつて使っていたKindle Paperwhite(第6世代)で開いてみても、やっぱりフリーズするので、まぁ、特定のメルマガのデータがKindleのファームウェアをフリーズさせてるんだろうなぁ。いやはや。

Sony「WF-1000XM4」とHUAWEI「freebuds 4i」

どちらもANC対応のワイヤレスヘッドホンではあるけれど、やはり、値段の差というか、同じApple Musicの音源を再生したとき(Androidだけど)の解像度がまるで違っていて驚いた。ある意味で、こんな音がなっていたんだって気づかされるくらいには違うかもしれない。

一応、Android機はPixel5なので、WF-1000XM4相手にはLDACをしゃべることができるけれど、コーデックの差とも言い切れない気がするんだけどなぁ。WF-1000XM4と同じくらいの価格のAppleのAirPods Proがどんな感じか気になるけれど、iPhoneでどんな感じかを確認しなきゃならず…なかなかだるいかもしれない。

Rocky Linuxでphpをビルドしようとしたらonigurumaが見つからなかったけども。

Rocky Linux release 8.4でphp 7.4.23をソースからビルドしようとしたら、onigurumaが見つからなくてビルドが失敗。いろいろ調べてみると、onigurumaのrpmはインストールされているけれど、oniguruma-develがインストールされていないようだった。なんにも考えずにdnf install oniguruma-develとかやってもパッケージが見当たらない。

onigurumaをソースからビルドするのもダルいし、なんでonigurumaはあってもoniguruma-develが見つからないんだ…と思って調べてみると、Rocky Linuxではデフォルトでenableになっていないレポジトリにoniguruma-develがあることがわかった。

/etc/yum.repo.dのRocky-PowerTools.repoを開いて、enabled=0をenabled=1に変更。その後で改めてdnf install oniguruma-develを実行してみると、何事もなかったようにインストールすることができた。あぁ、なるほど。

Rocky LinuxのPowerToolsってレポジトリは、開発関係のツールやライブラリが入っているパッケージであるようで、EPELに入っていたようなものが入っているらしい。まぁ、とりあえず、enableにしておいてもよさそうなレポジトリということで。改めてPHPをビルドしてみたら、何事もなかったようにビルドできた。

« Older posts