元祖ワシ的日記

毎年じわじわと増えてます。建物は一歳歳をとってるのに不思議

とあるサーバにrailsを入れる必要が出てきたんですが、こんなエラーでpumaが起動後お亡くなりになります。その原因の調査。

> bundle exec puma
/home/issei/cure_heart/vendor/bundle/ruby/3.2/gems/puma-6.6.0/lib/puma/puma_http11.so: [BUG] Segmentation fault at 0x0000000000000000
ruby 3.2.7 (2025-02-04 revision 02ec315244) [amd64-freebsd13]

-- Control frame information -----------------------------------------------
c:0012 p:---- s:0053 e:000052 TOP    [FINISH]
c:0011 p:---- s:0050 e:000049 CFUNC  :require
c:0010 p:0011 s:0045 e:000044 METHOD :37
c:0009 p:0035 s:0039 e:000038 TOP    /home/issei/cure_heart/vendor/bundle/ruby/3.2/gems/puma-6.6.0/lib/puma.rb:12 [FINISH]
c:0008 p:---- s:0036 e:000035 CFUNC  :require_relative
c:0007 p:0017 s:0031 e:000030 TOP    /home/issei/cure_heart/vendor/bundle/ruby/3.2/gems/puma-6.6.0/lib/puma/cli.rb:6 [FINISH]
c:0006 p:---- s:0028 e:000027 CFUNC  :require
c:0005 p:0011 s:0023 e:000022 METHOD :37
c:0004 p:0005 s:0017 e:000016 TOP    /home/issei/cure_heart/vendor/bundle/ruby/3.2/gems/puma-6.6.0/bin/puma:6 [FINISH]
c:0003 p:---- s:0013 e:000012 CFUNC  :load

--中略--
   0x85d9f7000    0x85da37000 rw-   64   64   1   0 ---- df 
   0x85e437000    0x85e439000 r--    2    2   3   0 ---- vn /usr/local/bin/ruby32
   0x85fa00000    0x85fde4000 r--  996  996   5   2 ---- vn /usr/local/lib/libruby32.so.32
   0x8607e4000    0x860804000 r--   32   32  47  20 ---- vn /lib/libthr.so.3
   0x861804000    0x8619dd000 r--  473  473  79  34 ---- vn /lib/libc.so.7
   0x8627dd000    0x8629d1000 r--  500  500   3   1 ---- vn /lib/libcrypto.so.7
   0x864800000    0x864ae6000 r--  742  742  39  14 ---- vn /lib/libcrypto.so.111
   0x8668e6000    0x86697b000 r--  149  149  39  14 ---- vn /usr/lib/libssl.so.111
0x1a2e9affd000 0x1a2e9b004000 r--    7   29  61  17 CN-- vn /libexec/ld-elf.so.1
0x1a2e9b004000 0x1a2e9b01a000 r-x   22   29  61  17 CN-- vn /libexec/ld-elf.so.1
0x1a2e9b01a000 0x1a2e9b01b000 r--    1    1   1   0 ---- df 
0x1a2e9b01b000 0x1a2e9b01c000 rw-    1    0   1   0 C--- vn /libexec/ld-elf.so.1
0x1a2e9b01c000 0x1a2e9b01e000 rw-    2    2   1   0 ---- df 
0x7ffffffff000 0x800000000000 r-x    1    1 183   0 ---- ph 

Abort (core dumped)

結論から先に言っておきます。これFreeBSDの秘伝のタレの問題でした。古いライブラリがバージョンアップで削除されていない問題です。

どうしてそこに至ったかというと、エラーからしてなんかSSL関係っぽいから。

で調べてみるとありました。めっちゃ古いファイルが。

$ ls -l /lib/libcrypt*
-r--r--r--  1 root  wheel    53264 May 18 10:09 /lib/libcrypt.so.5
-r--r--r--  1 root  wheel  3039112 May 18 10:09 /lib/libcrypto.so.111
-r--r--r--  1 root  wheel  2046848 Jun 13  2016 /lib/libcrypto.so.7
-r--r--r--  1 root  wheel  2046848 Jun 13  2016 /lib/libcrypto.so.7

/usr/libにもありました。

lrwxr-xr-x 1 root wheel 19 Nov 12 2014 libcrypto.so -> /lib/libcrypto.so.7

/lib/libcrypto.so.7を削除して、ln -s ../../libcrypto.so.111 /usr/lib/libcrypto.so を実行。pumaを再ビルドしたら無事に起動しました。

そもそもなんでこうなってしまったのか？まともにメンテをしてなかったからかもしれませんが、とにもかくにもfreebsd-updateで運用しているとよくあるんですよ。というかbashでもつい最近あったわけで。こういうエラーに遭遇しちゃうと知らないと解決が大変で・・・

とにかく、/libおよび/usr/libのタイムスタンプが異様に古いものは古いバージョンのものの可能性があるので削除。あるいは新しいものにsymbolic linkを切り替え。これが基本です。こんな古いライブラリが必要になるケースなんてほとんどないはずですし、そもそもメンテされてないライブラリを使っているアプリがあること自体ナンセンスです。

あと、ついでだから今このバージョンで真っ新からインストールしたらどのような配置になるのか。それを調べる方法も書いておきます。以下の場所にbase.txzってファイルがあるかと思います。ベースシステムはこの中に全部入っています。これをダウンロードしてきます。

https://download.freebsd.org/ftp/releases/amd64/13.5-RELEASE/

このファイルはタダのtarファイルなんで中身を見ることができます。全部見ると大変なんで ./libだけとってきて、さらにファイルを出力します（ディレクトリの最後の/はとりのぞく。これはあとでfindの結果と比較するため）。これが最新のbaseシステムです。

tar tfz /usr/dist/13.5-RELEASE/base.txz ./lib ./usr/lib | sed -e 's/\/$//' | sort > /base.list

これを find ./lib した結果と比較すればOKです。

find ./lib ./usr/lib|sort | diff -c base.list -

OpenAIにイラスト描いてもらいました。pumaに乗ってます。

秘伝のタレのように継ぎ足しながら運用しているFreeBSDにありがちな問題。以前もあったんですが、またまたupgradeで動かない問題。今回は以下のようなエラーが発生しました

# bash
ld-elf.so.1: Undefined symbol "rl_sort_completion_matches" referenced from COPY relocation in /usr/local/bin/bash

こんな感のエラーです。例によって問題は/lib以下に残っている古いライブラリなんでしょうけど、この探り方についてのメモを残しておきます。まずこのエラーが一体なんなのか？という説明。

多くのプログラムはdynamic linkというものを使ってビルドされています。これは実行時にlibraryをリンクするというもので最近の主流となっているものです。これの真逆はstatic linkで実行ファイルを作成するときにlibraryも一緒にリンクしちゃうことです。dynamic linkにすることでバイナリサイズを小さくできますし、ライブラリにバグが見つかったときでもライブラリだけの更新で済むと言う利点があります。

一方、dynamic linkは正しくlinkされないとダメということで同じ名前のライブラリが別なディレクトリなどにあったりするとうまく整合性が取れずこのようなエラーが発生している・・と予想できます。

実行ファイルやライブラリには、プログラム本体の他に「シンボル」と呼ばれる情報があります。シンボルというのは簡単にいえば関数名のようなもので、実行ファイルとライブラリのシンボル名を実行時にリンクして解決することで初めてプログラムがメモリ上に配置され実行できるようになるわけです。それを出力するコマンドが nmです。

nm -D /usr/local/bin/bash

を実行すると以下のような箇所がありました。

00000000002fac00 B rl_signal_event_hook
00000000002fabdc B rl_sort_completion_matches
00000000002f7b00 B rl_special_prefixes
00000000002fac10 B rl_startup_hook

左の数字はプログラムにおけるアドレスで右がシンボルになります。真ん中のBがそのシンボルの状態を表す記号。この場合BですのでBSSセクションに配置されているということになります。BSSセクションとはなんぞや？とかなるとリンカ沼にハマるので詳しくは解説しません・・（というか解説できません。私が知ってるのはDATAとかTEXTとか古くからあるやつだけでこいつらはプレステでゲーム作ってるときは重要だった。今はどうなんだろ？）。まぁ状態ということで認識しておけばよいかと思います。ちなみにBは解決済みです。じゃぁなんでエラーがでるんでしょうか？

そこでエラーメッセージに戻ります

COPY

の文字。これは「COPY relocation」という仕組みに関するエラーで領域はプログラム側に予約されているけれど、実体はライブラリ側にあるということです。それがうまく解決できていないと。

名称からしてreadlineの保管の問題っぽいので /libのあたりから探りをいれていきます。

ldd コマンドで何がリンクされているのかを確認します

# ldd /usr/local/bin/bash
/usr/local/bin/bash:
 libreadline.so.8 => /lib/libreadline.so.8 (0x3762cef30000)
 libhistory.so.8 => /usr/lib/libhistory.so.8 (0x3762cf42e000)
 libncursesw.so.9 => /lib/libncursesw.so.9 (0x3762d0296000)
 libintl.so.8 => /usr/local/lib/libintl.so.8 (0x3762d1029000)
 libdl.so.1 => /usr/lib/libdl.so.1 (0x3762d1e18000)
 libc.so.7 => /lib/libc.so.7 (0x3762d2de0000)
 libncurses.so.8 => /lib/libncurses.so.8 (0x3762d33ca000)
 libthr.so.3 => /lib/libthr.so.3 (0x3762d3d5e000)
 [vdso] (0x7ffffffff650)

ここで/libの下をみてみると

-r--r--r--  1 root  wheel   273064 Aug 28  2018 libreadline.so.8

というファイルがありました。あやしいです。これだけ2018年。

こではFreeBSDのアップデートの仕組みが関係しているようです。FeeBSDはfreebsd-update でアップデートをしたとしても古いライブラリをアップデートの際に削除しないようです（あるいはしていなかった？裏とってません）。つまりバージョンがあがって最新バージョンで無くなったとしてもそのライブラリは残しているわけです。削除してしまうとそのライブラリをリンクして動作していたプログラムが動かなくなるからということかと思いますがこれが秘伝のタレのような運用をしているサーバに悪影響を与えるわけです。

bashに関していえば /usr/local/lib/以下にもpkgから入れられたlibreadlineが存在しています。こちらをリンクするようにすれば解決するものと思われます。念の為コマンドをタイプ

# nm -D /usr/local/lib/libreadline.so.8 | grep rl_sort_completion_
0000000000051114 D rl_sort_completion_matches
# nm -D /lib/libreadline.so.8 | grep rl_sort_completion_

/usr/loca/lib/以下のほうには存在するようです。そこで強引にこちらのライブラリを優先的に検索するようにしてみます

env LD_LIBRARY_PATH=/usr/local/lib bash

はい、動きました。あとは /lib/libreadline.so.8をどうするかだけを考えればよいわけですが、基本的にpkgだけでアプリをいれているサーバなんでそんなものを使っているものが残っているはずもない・・ということでガッツリ削除することにしました。 ls -ltでタイムスタンプで並べ直してみると

-r--r--r--  1 root  wheel   314744 Dec 30  2022 libzfs.so.3
-r--r--r--  1 root  wheel    31800 Dec 30  2022 libufs.so.6
-r--r--r--  1 root  wheel   387320 Dec 30  2022 libncursesw.so.8
-r--r--r--  1 root  wheel   349640 Dec 30  2022 libncurses.so.8
-r--r--r--  1 root  wheel   216728 Dec 30  2022 libedit.so.7
-r--r--r--  1 root  wheel   273064 Aug 28  2018 libreadline.so.8
-r--r--r--  1 root  wheel    37000 Aug 28  2018 libkvm.so.6
-r--r--r--  1 root  wheel     7736 Aug 28  2018 libipx.so.5
-r--r--r--  1 root  wheel  2055072 Aug 28  2018 libcrypto.so.7
-r--r--r--  1 root  wheel   192040 Aug 28  2018 libcam.so.6
-r--r--r--  1 root  wheel  1722192 Apr  9  2014 libcrypto.so.6
-r--r--r--  1 root  wheel    34728 Dec  4  2012 libkvm.so.5
-r--r--r--  1 root  wheel    68360 Dec  4  2012 libmd.so.5

いやー結構ありますね。10年以上前から残っている秘伝のタレlibraryがたくさん・・・

これら全部削除してよいものだと思います。トラブルのもとなので。というか、たまたま動いているだけで、意図せずメンテナンスされていない古いライブラリが使われている可能性もあります。これはこれで問題ですよね？

OpenAIにイラスト描いてもらいました

何年も動いていたftpサーバ止めました。もういいよねって・・

こういう過去の遺物のようなものがセキュリティ突破の糸口になる時代です。どんどんなくしていきたい。

さらばFFFTP

OpenAIにイラスト描いてもらいました

この前大阪に来たばかりなのですが、某社からお呼ばれしたので今日も大阪です。万博の会期中は何時でも行くんでいくらでも呼んでくださいと言った手前約束は果たさねば。ということで打ち合わせを午前中で片付け午後から自由時間ができました。さっそく懸念事項である北大阪急行電鉄の箕面萱野に行くことにしました。実は5/5に千里中央は通過（というか乗り換え）してて、そこで二駅乗っておけば今日改めて乗る必要なかったんですが、家族が同行しているとなかなか難しく・・・結局本日までずれ込みました。

箕面萱野駅まで延伸したのは2024年の3月23日。いつでも行けると思ってんですが、気がつけば延伸して一年が経過してました。とりあえず夢洲は先日制覇したので、これにて近畿地方は完乗です。

乗るのだけが目標だから、到着後改札出て、写真撮って改札戻って、同じ電車に乗るいつものやつでした。残りは札幌のアレと沖縄のアレのみです。頑張ります。