讓 Byobu 的 status bar 使用 tmux multiline

tmux 在 2.9 的時候支援了 multiline,從 CHANGES 裡面可以看到說明:

Extend the #[] style syntax and use that together with previous format changes to allow the status line to be entirely configured with a single option.

Now that it is possible to configure their content, enable the existing code that lets the status line be multiple lines in height. The status option can now take a value of 2, 3, 4 or 5 (as well as the previous on or off) to configure more than one line. The new status-format array option configures the format of each line, the default just references the existing status-* options, although some of the more obscure status options may be eliminated in time.

Additions to the #[] syntax are: "align" to specify alignment (left, centre, right), "list" for the window list and "range" to configure ranges of text for the mouse bindings.

The "align" keyword can also be used to specify alignment of entries in tree mode and the pane status lines.

我桌機的螢幕是打直的,所以會希望拆成兩行儘量把 tmux 的 window 的資訊都顯示出來,不過我這邊還是希望保留 Byobu 的樣式,所以就翻到「Making byobu's (using tmux) status bar multi-line results in "session" and the date/time disappearing」這篇,作者貼了一個算是不完整的範例,看起來沒辦法直接用,所以還是得想辦法找出 Byobu 預設的 status-format[0]

後來找到的方法是在 Byobu 跑起來的環境裡面跑這個:

tmux display-message -p "#{status-format[0]}"

就會發現 status-format[0] 有夠大包... 接著把裡面的值拆開放到兩行,最後變成這樣 (這是從 Ubuntu 22.04 裡面的 Byobu 拆出來的):

source $BYOBU_PREFIX/share/byobu/profiles/tmux
set-option -g status 2
set -g status-format[0] '#[align=left range=left #{status-left-style}]#[push-default]#{T;=/#{status-left-length}:status-left}#[pop-default]#[norange default]#[list=on align=#{status-justify}]#[list=left-marker]<#[list=right-marker]>#[list=on]#{W:#[range=window|#{window_index} #{window-status-style}#{?#{&&:#{window_last_flag},#{!=:#{window-status-last-style},default}}, #{window-status-last-style},}#{?#{&&:#{window_bell_flag},#{!=:#{window-status-bell-style},default}}, #{window-status-bell-style},#{?#{&&:#{||:#{window_activity_flag},#{window_silence_flag}},#{!=:#{window-status-activity-style},default}}, #{window-status-activity-style},}}]#[push-default]#{T:window-status-format}#[pop-default]#[norange default]#{?window_end_flag,,#{window-status-separator}},#[range=window|#{window_index} list=focus #{?#{!=:#{window-status-current-style},default},#{window-status-current-style},#{window-status-style}}#{?#{&&:#{window_last_flag},#{!=:#{window-status-last-style},default}}, #{window-status-last-style},}#{?#{&&:#{window_bell_flag},#{!=:#{window-status-bell-style},default}}, #{window-status-bell-style},#{?#{&&:#{||:#{window_activity_flag},#{window_silence_flag}},#{!=:#{window-status-activity-style},default}}, #{window-status-activity-style},}}]#[push-default]#{T:window-status-current-format}#[pop-default]#[norange list=on default]#{?window_end_flag,,#{window-status-separator}}}'
set -g status-format[1] '#[align=right]#(byobu-status tmux_right)'$BYOBU_DATE$BYOBU_TIME

我要的效果就出來了:

維基基金會 (包括維基百科) 的官方服務狀態頁

看到「Announcing www.wikimediastatus.net」這個,維基基金會相關服務的官方狀態頁:「www.wikimediastatus.net」。

從頁面下面的「Powered by Atlassian Statuspage」這邊可以看出來是使用 Statuspage 這個服務。

看起來當 server error 狂噴的時候這邊應該有機會看到 (剛好前陣子好像有發生),另外 Total request volume 這個指標也透漏了目前整個維基基金會服務尖峰會有 150Kreqs/sec 的量,可以預期大多數應該都是維基百科相關的服務...

不過大多數的量應該都是從 cache server 吐出去,不知道有沒有後端 PHP loading 的數字...

MySQL (InnoDB) 的內部狀態

Percona 老大 Peter Zaitsev 在「MySQL – A Series of Bad Design Decisions」這篇裡提到了他認為 MySQL 設計上的問題,不過裡面也提到了不少有用的指令,平常可以先熟悉一下輸出,等真的有狀況的時候才會想起來可以用這些指令。

首先是最經典的 SHOW ENGINE INNODB STATUS,算是很多文件上面都會提到的指令。可以看 InnoDB 當下的情況,藉以猜測內部現在是怎麼卡住...

另外一個是 SHOW ENGINE INNODB MUTEX,就如同 Peter Zaitsev 所提到的,這個指令想辦法抓出最重要的資訊,但不要像 SHOW ENGINE INNODB STATUS 給了那麼多。

另外當然就是 INFORMATION_SCHEMA,他甚至希望 SHOW ENGINE INNODB 系列的指令應該要被整合進去,這樣才能用 SELECT 相關的指令整理... (因為 ORDER BY 以及蠻多的指令沒辦法在 SHOW ... 上面用)

用 IPFS 放 Status Page

Hacker News Daily 上看到的專案,拿 IPFS 來放 Status Page 真的超適合的,靜態為主,然後又可以避開 SPoF:「Decentralized StatusPage」。程式碼放在 GitHubpaulogr/dstatuspage,以 JavaScript 撰寫。

Hacker News 上的討論也蠻有趣的:「Show HN: A Decentralized StatusPage on IPFS | Hacker News」。

IPFS 提供的特性與 Status Page 需要的特性其實還蠻契合的,也許不是 killer application,但應該會是個 IPFS 的出發點...

而且最近 Firefox 在他們的 blog 上發表了 Firefox 59 會將一些分散式協定加進去 (不是實做,而是提供接口):「Extensions in Firefox 59」(參考 Support for Decentralization Protocols 這段),這感覺讓 IPFS 之類的協定有更寬廣的舞台...

GitHub 支援 HTTP Code 451 了...

GitHub 宣佈支援 HTTP Code 451 了:「The 451 status code is now supported」。也就是 RFC 7725 的「An HTTP Status Code to Report Legal Obstacles」。

目前會把因為 DMCA takedown notice 下架的內容以 HTTP Code 451 標出:

The GitHub API will now respond with a 451 status code for resources it has been asked to take down due to a DMCA notice.

HTTP Code 451 的點子出自「華氏 451 度」這本書,表示紙的燃點。

GitHub 提供更輕量的 Commit Reference SHA-1 API

GitHub 提供了新的 API 讓 client 可以更省網路資源,同時 GitHub 本身也可以省下 query。雖然是 Preview 期間,但已經有專案開始用了:「Commit Reference SHA-1 Preview Period」。

本來是這樣抓:

curl "https://api.github.com/repos/Homebrew/homebrew/commits/master" \
  -H "Accept: application/vnd.github.chitauri-preview+sha"

現在則可以加上 If-None-Match

curl "https://api.github.com/repos/Homebrew/homebrew/commits/master" \
  -H "Accept: application/vnd.github.chitauri-preview+sha" \
  -H "If-None-Match: \"814412cfbd631109df337e16c807207e78c0d24e\""

當本地與遠端的 SHA-1 值一樣時會收到 304,而且不會吃 rate limit quota:

If the remote and your local branch point to the same SHA-1 then this call will return a 304 Unmodified status code (and not use your rate limit).

尤其是當 commit reference 指到的 commit 特別大包時,可以省下很多資源...

HTTP Status Code 451

前陣子送出的 HTTP Status Code 451 要通過成為標準了:「Why 451?」。

Today, the IESG approved publication of "An HTTP Status Code to Report Legal Obstacles". It'll be an RFC after some work by the RFC Editor and a few more process bits, but effectively you can start using it now.

取自「華氏451度」這部講出版物言論自由的作品 (紙的燃點是華氏 451 度),在 Internet 時代,451 剛好在 HTTP Status Code 4xx 的範圍,被拿來用做「因法令限制而服法提供內容的 Status Code」。

在文件開頭說明了這個代碼的用途:

This document specifies a Hypertext Transfer Protocol (HTTP) status code for use when resource access is denied as a consequence of legal demands.

GitHub 支援 Protected Branches 了...

GitHub 宣布支援 Protected Branches 了:「Protected branches and required status checks」,其他的競爭對手都有的功能:

Over the next few weeks we’ll be rolling out a new feature called Protected Branches which gives repository administrators the ability to disable force pushes to specific branches.

另外一起引入的是強制性的檢查:

算是補功能... 組織變大的時候必須透過系統強制介入的功能。

MySQL InnoDB 遇到 Deadlock 時的判讀

Percona 的「How to deal with MySQL deadlocks」這篇文章裡面提到了 MySQL InnoDB Deadlock 的判讀與處理。

在支援 transaction 的 engine 裡 deadlock 是不可避免的常態。

在 MySQL 5.5 以及之前的版本,可以透過 Percona 的 pt-deadlock-logger 這隻 script,每固定幾秒鐘就跑一次 SHOW ENGINE INNODB STATUS 記錄下來。在 MySQL 5.6 之後,可以直接使用 innodb_print_all_deadlocks 這個參數,遇到 deadlock 時就寫到 error log 裡。

有了 log 後,接下來就可以判讀 deadlock 的情況,得知是什麼樣的情況造成 deadlock。

文章最後面則是對減少 deadlock 的方法給了一些建議,都是比較一般性。一般還是要靠 bussiness logic 的分析來切割降低 deadlock 的情況。

不過這篇文章需要一些背景知識,像是 InnoDB Lock Modes 與維基百科上的「Multiple granularity locking」,對解讀會有更多幫助。