ほぼ雑記的メモ
毎年じわじわと増えてます。建物は一歳歳をとってるのに不思議
とあるサーバに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を再ビルドしたら無事に起動しました。
/lib/libcrypto.so.7
ln -s ../../libcrypto.so.111 /usr/lib/libcrypto.so
そもそもなんでこうなってしまったのか?まともにメンテをしてなかったからかもしれませんが、とにもかくにもfreebsd-updateで運用しているとよくあるんですよ。というかbashでもつい最近あったわけで。こういうエラーに遭遇しちゃうと知らないと解決が大変で・・・
freebsd-update
とにかく、/libおよび/usr/libのタイムスタンプが異様に古いものは古いバージョンのものの可能性があるので削除。あるいは新しいものにsymbolic linkを切り替え。これが基本です。こんな古いライブラリが必要になるケースなんてほとんどないはずですし、そもそもメンテされてないライブラリを使っているアプリがあること自体ナンセンスです。
/lib
/usr/lib
あと、ついでだから今このバージョンで真っ新からインストールしたらどのような配置になるのか。それを調べる方法も書いておきます。以下の場所に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
find ./lib ./usr/lib|sort | diff -c base.list -
OpenAIにイラスト描いてもらいました。pumaに乗ってます。
秘伝のタレのように継ぎ足しながら運用しているFreeBSDにありがちな問題。以前もあったんですが、またまたupgradeで動かない問題。今回は以下のようなエラーが発生しました
# bashld-elf.so.1: Undefined symbol "rl_sort_completion_matches" referenced from COPY relocation in /usr/local/bin/bash
# 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_hook00000000002fabdc B rl_sort_completion_matches00000000002f7b00 B rl_special_prefixes00000000002fac10 B rl_startup_hook
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)
# 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が存在しています。こちらをリンクするようにすれば解決するものと思われます。念の為コマンドをタイプ
/usr/local/lib/
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_
# 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でタイムスタンプで並べ直してみると
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
-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 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
この前大阪に来たばかりなのですが、某社からお呼ばれしたので今日も大阪です。万博の会期中は何時でも行くんでいくらでも呼んでくださいと言った手前約束は果たさねば。ということで打ち合わせを午前中で片付け午後から自由時間ができました。さっそく懸念事項である北大阪急行電鉄の箕面萱野に行くことにしました。実は5/5に千里中央は通過(というか乗り換え)してて、そこで二駅乗っておけば今日改めて乗る必要なかったんですが、家族が同行しているとなかなか難しく・・・結局本日までずれ込みました。
箕面萱野駅まで延伸したのは2024年の3月23日。いつでも行けると思ってんですが、気がつけば延伸して一年が経過してました。とりあえず夢洲は先日制覇したので、これにて近畿地方は完乗です。
乗るのだけが目標だから、到着後改札出て、写真撮って改札戻って、同じ電車に乗るいつものやつでした。残りは札幌のアレと沖縄のアレのみです。頑張ります。