2016/05/04

Agda 2.5.1 でライブラリのパスを設定する

Agda のバージョンを上げたらライブラリのパスの指定方法が変わったらしいので再設定したログ。


環境

  • Mac OSX Yosemite 10.10.5
  • GHC 7.10.3
  • cabal-install 1.22.9.0
  • Agda 2.5.1
  • agda-stdlib 0.12.0 (84ad2bf993e8256e8989f5466c0db0817473b2d6)


設定方法

前までは init.el 辺りで agda2-include-dirs に library の path を list で設定する方法だったのですが、 2.5.1 からは agda2-program-args に入れるか library mamangement を使えとのこと

library management は特定のフォーマットでライブラリのパスや依存が書けるものらしいですが、使ってるライブラリもそんなに無いので agda2-program-args を指定する方法でやってみます。
-iDIR か -lLIB 辺りのフォーマットにして設定しろとのことです。

私は使うライブラリを ~/Library/Agda2 の下に symlink を貼る形にしてるので、 ~/Library/Agda2/* を展開してフルパスにして -i を付けて設定してます。

具体的にはこんな感じ。
(setq agda2-program-args (mapcar (lambda (path) (concat "-i" (expand-file-name path))) (file-expand-wildcards "~/library/Agda2/*")))
ちなみに前まではこんな感じ。
(setq agda2-include-dirs (mapcar (lambda (path) (expand-file-name path)) (file-expand-wildcards "~/Library/Agda2/*")))
(add-to-list 'agda2-include-dirs ".")
設定したら無事動いてめでたしめでたし。


参考

2016/04/30

NFS と intr オプション

CentOS 7 で NFS を mount しているとたまに kernel がハングする時があったのでそのログとか対処法とか。


環境


  • CentOS : 7.1.1503
  • kernel : 3.10.0-327.4.5.el7.x86_64 (だったと思う)
  • nfs-utils : 1.3.0-0.21.el7.x86_64


状況

/var/log/messages を見ると
hogehoge kernel: nfs: server 10.20.30.40 not responding, still tryinghogehoge kernel: nfs: server 10.20.30.40 not responding, timed out
とか出てる。どうやら nfs までのネットワークか nfs 本体が不安定な時があるらしい。

最悪の場合のログがこれ。 ssh すらできなくなる。
INFO: task kworker/u289:1:113889 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kworker/u289:1  D ffff885eff613680     0 113889      2 0x00000080
Workqueue: writeback bdi_writeback_workfn (flush-0:36)
ffff885c819e7c88 0000000000000046 ffff885e59db0000 ffff885c819e7fd8
ffff885c819e7fd8 ffff885c819e7fd8 ffff885e59db0000 ffff885ca53efd90
ffff88607ff66220 0000000000000080 0000000000000000 ffff885e64f15268
Call Trace:
[<ffffffff816098d9>] schedule+0x29/0x70
[<ffffffff811f066a>] inode_sleep_on_writeback+0x9a/0xd0
[<ffffffff81098240>] ? wake_up_bit+0x30/0x30
[<ffffffff811f1aa0>] wb_writeback+0x170/0x2f0
[<ffffffff811f31cb>] bdi_writeback_workfn+0x2cb/0x460
[<ffffffff8108f0cb>] process_one_work+0x17b/0x470
[<ffffffff8108fe9b>] worker_thread+0x11b/0x400
[<ffffffff8108fd80>] ? rescuer_thread+0x400/0x400
[<ffffffff8109727f>] kthread+0xcf/0xe0
[<ffffffff810971b0>] ? kthread_create_on_node+0x140/0x140
[<ffffffff81614358>] ret_from_fork+0x58/0x90
[<ffffffff810971b0>] ? kthread_create_on_node+0x140/0x140
INFO: task scp:114899 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
scp             D ffff885eff533680     0 114899      1 0x00000080
ffff885d75dafb78 0000000000000082 ffff88bce8d14fa0 ffff885d75daffd8
ffff885d75daffd8 ffff885d75daffd8 ffff88bce8d14fa0 ffff885eff533f48
ffff88607ff624e8 0000000000000002 ffffffff811562e0 ffff885d75dafbf0
Call Trace:
[<ffffffff811562e0>] ? wait_on_page_read+0x60/0x60
[<ffffffff81609bdd>] io_schedule+0x9d/0x130
[<ffffffff811562ee>] sleep_on_page+0xe/0x20
[<ffffffff816079b0>] __wait_on_bit+0x60/0x90
[<ffffffff81156076>] wait_on_page_bit+0x86/0xb0
[<ffffffff81098280>] ? autoremove_wake_function+0x40/0x40
[<ffffffff811561b1>] filemap_fdatawait_range+0x111/0x1b0
[<ffffffff81156277>] filemap_fdatawait+0x27/0x30
[<ffffffff811f0568>] __writeback_single_inode+0x1b8/0x220
[<ffffffff811f1467>] writeback_single_inode+0xe7/0x1b0
[<ffffffff811f156e>] sync_inode+0x3e/0x60
[<ffffffffa06ea1bc>] nfs_wb_all+0x5c/0x100 [nfs]
[<ffffffffa06df410>] nfs_setattr+0x1e0/0x1f0 [nfs]
[<ffffffff811e3739>] notify_change+0x279/0x3d0
[<ffffffff811c4b13>] do_truncate+0x73/0xc0
[<ffffffff811c9168>] ? __sb_start_write+0x58/0x110
[<ffffffff811c4ea4>] do_sys_ftruncate.constprop.17+0x114/0x170
[<ffffffff811c4f3e>] SyS_ftruncate+0xe/0x10
[<ffffffff81614409>] system_call_fastpath+0x16/0x1b
/home を nfs の上に置いてるからかもしれないけれど何もできなくなるので、だいたい再起動することになる。
負荷が高い時に発生するのかと思って再現させようとしても耐える時は耐える。
特に私が見てない時に他の人が使って止まってしまったことがほとんどなので、原因も対処方も若干憶測が入ってるのがちょっとつらい。


対処

クライアント側で intr オプション付けると良さそう。 mount コマンドなら
$ mount --verbose -t nfs -o intr 10.20.30.40:/path/to/mount-target /path/to/mount-point
とか。 /etc/fstab だと hard/soft の部分を hard,intr にする。
nfs のマウントには soft と hard の二種類があって、soft は NFS サーバが応答しなくなった時にエラーを返すらしい。
でも帰ってきたエラーをアプリケーション側が上手くハンドルしないとファイル壊れちゃうので hard が推奨。
hard はサーバが応答しなくなっても待ち続ける。soft のようにファイルが壊れることもないらしいし、一時的にサーバが落ちても大丈夫なのでNFSサーバの再起動とかしても問題無い。
けれど待ち続けてる間で kernel task が 120 秒とかを越えると kernel panic しちゃうみたい。
hard を付けた状態で panic するんじゃなくて kernel が task を止められるように intr を付けておくと panic しなくなった。
設定後4ヶ月くらい様子を見ているけれど再現はしていないっぽい。


まとめ

NFS の mount option に hard を指定する場合は intr も一緒に付けておいた方が良さそう。


参考

2015/12/23

FreeRADIUS を使って複数のインターフェースで DHCP サーバを動かす

FreeRADIUS を使って DHCP サーバを提供している時に複数の interface を使って DHCP を提供する必要があったのでその方法とか。

前回の記事にも書いたのですが、FreeRADIUS で DHCPサービスを提供する場合は
/etc/raddb/sites-available にあるサービスを /etc/raddb/sites-enabled にリンクを貼ることで有効化する様子。

ということでまずは /etc/raddb/sites-available にある dhcp をコピーして listen する interface を変更。
そのリンクを /etc/raddb/sites-enabled に貼ると複数のインターフェースにも対応できます。

例えば /etc/raddb/sites-available/dhcp.private と /etc/raddb/sites-available/dhcp.global みたいな感じ。


これで個別の interface ごとに違う設定を適用した複数の DHCP サーバを提供することできます。

2015/12/06

Homebrew で debug symbols を埋め込んだ LLVM の bottle を作る

Homebrew の bottle を使って debug information が埋め込まれた LLVM を配ってみんなで読もう、ということになったのでそのログ。


環境

  • OSX Yosemite 10.10.5
  • Homebrew 0.9.5
  • LLVM 3.8
  • あと自分のマシンじゃないのでチェックしてないけれど El Capitan (10.11.1?)


Release Build の LLVM の bottle 化

私が所属している研究室では Continuation Based C (CbC) という言語を開発していて、LLVM implemented 版があるのでまずはそいつで bottle で作れないかをチェック。
formula は github の ie-developers/ie/cbc にあります。

普通に build した LLVM を bottle にするのは結構簡単で、
  • brew install --build-bottle ie-developers/ie/cbc
  • brew bottle cbc
とか。 これで build された binary を固めたやつが current directory にできます。
ついでにこうやって書いてね、って出力が sha256 と共に出てくるのでそいつを formula に追記して、 bottle を公開用サーバか何かに置けばOK.


LLVM 3.8 の build を bottle 化

いつからか LLVM は build を repository の top でやると怒るようになってます。
具体的には ./configure をすると怒ってくる。
そいつを回避するために Homebrew 公式の llvm は mktemp を使っているようです。
なので mktemp を使ってやれば最近の LLVM も bottle 化することができます。


LLVM 3.8 を debug information 付きで build して bottle 化

ひとまず LLVM 3.8 を debug information 付きで build する手順としては

  • git clone http://llvm.org/git/llvm
  • mkdir llvm_build
  • cd llvm_build
  • ../llvm/configure --enable-debug-runtime --enable-debug-symbols --disable-optimized --enable-assertions
  • make -j 3
とか。
Debug+Assets って directory に bin と lib ができるのでそいつで追えます。
具体的には
  • lldb Debug+Assets/bin/clang
とかできます。


LLVM 3.8 を debug information 付きで build

Homebrew は build する時のディレクトリは build 時に生成して install 後に捨ててしまうっぽいです。
なので build 場所を変えてバイナリを残すように。
formula の prefix ってメソッドがインストール先のディレクトリを返してくれるので、その下で build しちゃいます。(ちなみに prefix の値は "/usr/local/Cellar/llvm_original/llvm3.8/" とか。)

インストール先のディレクトリで直接 build するれば、Debug+Assets が bottle に入るんじゃないかって魂胆。
あと、 Homebrew は make する時に CFLAGS とかを変更しちゃう superenv ってのがあるらしく、そいつは勝手に -g とかを落とすっぽいです。
なので build する時に --env=std とかすると良いらしい

ってなわけで
  • brew install --env=std --build-bottle ie-developers/ie/llvm_original
  • brew bottle
とかすると OK。
ちなみに圧縮前は8.9Gで圧縮後は2.1Gほど。
あと LLVM はとりあえず make するとこで止めてます。ファイル多くなっちゃいますし。


bottle を展開して lldb で追う

あとは落として追えば良いです。
が、 brew が build 時に buildpath を /private/tmp に作っちゃうのでそのパスを解決してやれば良い。

とか。

これで
  • lldb /usr/local/Cellar/llvm_original/llvm3.8/build/Debug+Asserts/bin/clang
  • l main
とかしてソースが表示されます。やったね。
ちなみにこの path は Yosemite の場合なので El Capitan の path はまた別です。
lldb が l main して時にファイルが無いって文句言うはずなのでそれを解決できように symlink 貼れば良いはず。


よもやまばなし

以下適当に本筋と関係無い話。

Cmake で build

Brew 公式の lldb は cmake で make してるっぽいです。
formula の中では std_cmake_args ってものを持ってるらしく、そいつが  -DCMAKE_BUILD_TYPES=Release を突っこむっぽいです。
なので CMAKE_BUILD_TYPES=Debug とか入れても弾かれる。
RelWithDebugInfo とかもあるのでそいつでもいけるかも?

superenv を見つけた話

どうも -g が有効じゃないっぽいのでログを漁ってたら
  • superenv removed:  -g -Wcast-qual -m64 -Wall -W -Wwrite-strings

とかあったので調べてみました。ログつよい。
ちなみにログの場所は
  • less ~/Library/Logs/Homebrew/llvm_original/02.make.cc
とかです。
superenv は -g を落として -O2 とかを入れてくれるっぽいので brew は Debug Build は基本入れない方針っぽいです。
もちろん --env=std で回避手段があるのは流石ですが。

Mach-O

ちなみに -g が効かないのを探すために Mach-O の仕様とか dSYM とか DWARF とか symbols コマンドとか dsymutil とか調べたりしてました。
その辺の hello.c とかコンパイルすると dSYM が作られて、そいつを消すと追えなかったのでこの辺が問題なのかなー、とか思ってゴニョゴニョしてました。
結果的にはハズレか。

make install してない

どうせ Debug+Assets が残ってないと追えないので make install はしてません。
なので brew link とかは効かないです。
make install した clang も Debug+Assets の debug symbols を見にいくはずなので、二重に clang 作るのは容量的に勿体ないかな、と。


参考文献とか

2015/11/18

FreeRADIUS 3.0.4 で DHCP サーバを立てる時に気をつけること

FreeRADIUS 3.0.4 を使って DHCP を使っているとたまに SEGV することがあったのでその原因を探ってみたメモ。
なんとなーく高負荷時くらいに発生するようですが、負荷が低い時にも発生するので core dump を取ってきちんと追ってみました。


環境

  • OS : CentOS 7.1.1503
  • FreeRADIUS : 3.0.4


abrtd の設定

SEGV だけじゃ原因が分からないのでまずは coredump を取るように設定。
abrt なるものがあるらしいので使ってみる
  • # yum install -y abrt-cli
  • # vim /etc/security/limits.d/core.conf
    • *       hard        core        unlimited
    • *       soft        core        unlimited
    • くらいに設定。 core のファイルを作るように。
  • # vim /etc/sysctl.d/50-core.conf
    • kernel.core_uses_pid = 1
    • fs.suid_dumpable = 2
    • Storage = both
    • くらいで。
  • # vim /etc/sytemd/system.conf
    • DumpCore を yes,  DefaultLimitCORE を unlimited に
  • # systemctl enable abrtd
  • # reboot

これで core が取れるようになった。
coredump の場所は abrt が設定するようで /var/spool/abrt/ くらい。


coredump から原因を追う

  • # gdb /var/spool/abrt/ccpp-2015-11-04-09\:39\:18-2478/coredump
    • すると debuginfo が無いので入れろと言ってくる
  • # yum --enablerepo='*debug*' install /usr/lib/debug/.build-id/9c/9089cc84962eae11b31e65e92af30874f83b2c
    • 言われた通りに打つと入る。便利。
どうやら
  • #0  fr_packet_cmp (a=0x7f068be885a0, b=0xcb6b5c9a1101f601) at src/lib/packet.c:45
とかで SEGV している様子。

back trace は

  • #0  fr_packet_cmp (a=0x7f068be885a0, b=0xcb6b5c9a1101f601) at src/lib/packet.c:45
  • #1  0x00007f06894c9eea in rbtree_find (tree=0x7f068bed05a0, data=data@entry=0x7fff68b1cdb8) at src/lib/rbtree.c:517
  • #2  0x00007f06894d0f8f in fr_packet_list_yank (pl=0x7f068bed0fc0, request=0x7f068be885a0) at src/lib/packet.c:559
  • #3  0x00007f0689b5e1ff in request_done (request=request@entry=0x7f068be3d070, action=action@entry=2) at src/main/process.c:636
  • #4  0x00007f0689b5e6ad in request_process_timer (request=0x7f068be3d070) at src/main/process.c:908
  • #5  0x00007f0689b624bd in request_common (request=request@entry=0x7f068be3d070, action=<optimized out>) at src/main/process.c:1122
  • #6  0x00007f0689b632a5 in request_cleanup_delay (request=0x7f068be3d070, action=<optimized out>) at src/main/process.c:1176
  • #7  0x00007f06894d1a1f in fr_event_run (el=el@entry=0x7f068bbb4f00, when=when@entry=0x7fff68b1d040) at src/lib/event.c:260
  • #8  0x00007f06894d1fd9 in fr_event_loop (el=0x7f068bbb4f00) at src/lib/event.c:482
  • #9  0x00007f0689b63d61 in radius_event_process () at src/main/process.c:4983
  • #10 0x00007f0689b42758 in main (argc=3, argv=<optimized out>) at src/main/radiusd.c:584

とか。

request の管理は rbtree でやっていて、その rbtree で find や insert する時の比較ルーチンで落ちてるみたいです。
他の dump もいくつか見るとやっぱり rbtree 周り。
request_done すると request_hash から外す時に rbtree_insert とかするっぽいですね。
コードを読んでいくと nodup なるものが true ならそのルーチンは呼ばれないみたいです

git grep nodup すると読んだ時の最新の 3.0.9 では DHCP は default で nodup が true の様子
そして CentOS7 の yum で入る 3.0.4 では nodup は true では無いみたいです。

ということで
/etc/raddb/sites-enabled/dhcp
performance { skip_duplicate_checks = yes }
を追加しておしまい。しばらく運用しても SEGV することはなくなりました。


再現してみる

とりあえず運用している radiusd は落ちなくなったのですが原因が本当にコレかチェックしてみます。


再現環境

  • OS : OSX Yosemite 10.10.5
  • Docker : 1.9
  • docker-machine : 0.5.0
  • Virtualbox : 5.0.10 r104061


再現方法

前回作った FreeRADIUS のサーバで試してみます。
Docker で container を上げると '02:42:ac:11:00:??' の mac address が自動生成されるようなのでそれに対して適当にダミーのデータを投入します
  • 256.times{|n| IpAddress.create!(address:n, mac_address: format('02:42:ac:11:00:%02x', n))}
この状態で dhclient だけが入っている container を100個くらい起動。
そうすると SEGV しました。数度再現するのでこれが原因っぽいです。
そして nodup を設定してまた負荷をかけてみます。
今度は SEGV しません。原因はやっぱりこれのようですね。


まとめ

FreeRADIUS 3.0.4 で DHCP サーバを上げる場合は nodup の設定をしておきましょう。
CentOS 7 の yum で入る FreeRADIUS は 3.0.4 です。
また、FreeRADIUS 3.0.8 ではデフォルトで有効なようなので、この設定はしばらくすると必要無くなります。


参考URL