htop の uptime に謎のビックリマーク(!)がつく理由

2023年12月07日木曜日

【この記事を書いた人】
古賀勇

IIJ ネットワーク本部アプリケーションサービス部・(兼)社長室所属。メールサービスの運用業務に従事し、日々世界の悪と戦う一児の父親。社内 Power Automate エバンジェリスト(自称)。M3AAWG member / openSUSE Users / WIDE Project メンバー。趣味は大喜利。はがき職人。

【IIJ 2023 TECHアドベントカレンダー 12/7の記事です】

ネットワーク機器やサーバを管理していると、uptime が気になるのが人情というものです。

なぜなら起動してからの稼働日数を示す uptime は、そのシステムが安定して稼働していたことを示す、可用性・信頼性の一つの指標になるからです^(※1)。IIJ でも古い機器が役目を終え、いざシャットダウンしようとするときに、この uptime がたびたび社内で話題になり、それだけでひと盛り上がりします。^(※2) ^(※3)

ふと自宅のサーバで htop を見ていたら、uptime の横に (!) マークが付いていることに気づきました。

htop コマンドは、CPU の負荷状況や、メモリの利用状況、プロセスツリーをグラフィカルに表示してくれるだけでなく、ノート PC ならバッテリー残量なども含めてシステムの状態を把握できる、レガシーな top の代替となる素晴らしいコマンドです。なので、これもなにかの警告を示しているに違いありません。

しかし、そう思って htop のマニュアルを見ても、一切書かれていないのです。
それなら、ソースコードを見るしかない。

https://github.com/htop-dev/htop/blob/main/UptimeMeter.c#L36

(if 文の条件分岐で「uptime の日数が 100 より大きい」ときは days の後ろに (!) マークが付くようになっている)

このコードを仕込んだコミッターを調べてみよう。Git だから blame すればすぐに分かるはずだ。

$ git blame UptimeMeter.c
 
09e241fb (Hisham Muhammad 2017-07-27 16:07:50 -0300 34)    char daysbuf[32];
33113fe0 (Hisham Muhammad 2006-04-10 20:40:38 +0000 35)    if (days > 100) {
09e241fb (Hisham Muhammad 2017-07-27 16:07:50 -0300 36)       xSnprintf(daysbuf, sizeof(daysbuf), "%d days(!), ", days);
33113fe0 (Hisham Muhammad 2006-04-10 20:40:38 +0000 37)    } else if (days > 1) {
09e241fb (Hisham Muhammad 2017-07-27 16:07:50 -0300 38)       xSnprintf(daysbuf, sizeof(daysbuf), "%d days, ", days);
33113fe0 (Hisham Muhammad 2006-04-10 20:40:38 +0000 39)    } else if (days == 1) {
09e241fb (Hisham Muhammad 2017-07-27 16:07:50 -0300 40)       xSnprintf(daysbuf, sizeof(daysbuf), "1 day, ");

Hisham Muhammad さんって人ですね、なるほど。彼はどんな活動をしている人なんだ?

htop の作者だった…。

よくよく調べたら Github でも Issue になっていました。

Remove exclamation point with > 100 days uptime #614
https://github.com/htop-dev/htop/issues/614

we discussed your proposal in the core team and decided to keep the functionality.
The rationale is:

Not having rebooted a system 100+ days is noteworthy

Most people get the meaning of the (!) intuitively (we’ve had zero support requests for this)

It is a historic feature

We are generally pro-easter-eggs. These are a cultural feat for software that is made artisanal

一応、htop のイースターエッグということらしいですが、インフラエンジニアからしてみれば 100日稼働なんて朝飯前の uptime です。検索してみたら、同じように思っている人もいるようでした。

Why does HTOP show exclamation mark next to uptime
https://stackoverflow.com/questions/26469294/why-does-htop-show-exclamation-mark-next-to-uptime
What does the (!) mean after uptime on htop
https://unix.stackexchange.com/questions/150121/what-does-the-mean-after-uptime-on-htop/351864

そして途中から混ぜ込んだのかと思いきや、だいぶ前から入っていました。少なくとも 2006年の htop 0.6.1 にはあったようです。
https://github.com/hishamhm/htop/releases/tag/0.6.1

結論

htop は uptime が 100日を越えると “(!)” が付く。それ以外に意味はない。

脚注

一方で、再起動しないことは、毎日のようにセキュリティの更新が出ている Linux カーネルやファームウェアが古いままであり危険な可能性がある、という指摘もごもっともです。IIJ では対象となるすべての脆弱性のリスク度合いを確認・検証し、緊急度に応じて適切に対処していますのでご安心ください(必要なときは再起動します)。[↑]
少し昔の話ですが、メールシステムの古い設備のシャットダウン作業をしていたら、機器の uptime と、プロセスの起動時刻が一致しているのを発見したことがあります。そう、IIJ で開発し、送信ドメイン認証の検証 milter としてオープンソースで公開している、安定と信頼性の YENMA です。[↑]
uptime コマンドで表示される経過日数から起動日を算出するときに、date コマンドを使ってこんな風に調べていました。
```
$ date --date "1234 days ago"
2020年  7月 21日 火曜日 00:00:00 JST
```
ところが、この記事を書いているときに、もっと簡単に求められるコマンドを発見しました。(私が知らなかっただけ) [↑]
```
$ who --boot
         システム起動 2023-07-20 00:00
```
uptime といえば、SUSE が公開している Uptime Funk というパロディ動画がオススメなので、openSUSE もオススメです(宣伝)。Don’t reboot it just patch!
https://www.youtube.com/watch?v=SYRlTISvjww