隠居日録

隠居日録

2016年(世にいう平成28年)、発作的に会社を辞め、隠居生活に入る。日々を読書と散歩に費やす

perlとchromecastその後

chromecastを使った後についつい電源を切らずに放置してしまうことがたまにあったので、nanopi NEO2で一日一回早朝にchromecastが動いているかどうか確認するようにした。早朝なら通常寝ているはずだし、その時間にchromecastが動いているのが検出されたら、電源の切り忘れの可能性が高いからだ。そして、昨日久しぶりに、chromecast電源を切るのを忘れた。通常ならばchromecastが検出されたことが、ローカルメールで通知されるだけなのだが、奇妙なメールがやってきた。

***  FATAL PROGRAM ERROR!!	Unknown instance method "char_str_list"
***  which the program has attempted to call for the object:
***
Chromecast-73ae3b0d75f33a65aeb362aa7b2fa400._googlecast._tcp.local.	120	CLASS32769	SRV	(
	0 0 8009 73ae3b0d-75f3-3a65-aeb3-62aa7b2fa400.local. )
***
***  THIS IS A BUG IN THE CALLING SOFTWARE, which incorrectly assumes
***  that the object would be of a particular type.  The type of an
***  object should be checked before calling any of its methods.
***
Net::DNS::RR::SRV 1597 at /usr/local/lib/perl5/site_perl/Net/Bonjour/Entry.pm line 257.
	Net::Bonjour::Entry::mfetch(Net::Bonjour::Entry=HASH(0x41a3d030)) called at /usr/local/lib/perl5/site_perl/Net/Bonjour.pm line 335
	Net::Bonjour::discover(Net::Bonjour=HASH(0x40b4d6c0)) called at /usr/local/lib/perl5/site_perl/Net/Bonjour.pm line 193
	Net::Bonjour::_init(Net::Bonjour=HASH(0x40b4d6c0), "googlecast", "tcp", "local") called at /usr/local/lib/perl5/site_perl/Net/Bonjour.pm line 179
	Net::Bonjour::new("Net::Bonjour", "googlecast", "tcp", "local") called at detect.pl line 14

今までこんなことは起きていなかったので、何事かと思ったのだが、char_str_listが存在していないのに、使おうとしているのが問題のようだ。何か想定外のことが起きているのだろうが、再現性はどうなのだろうと、試してみたら、やはり同じメッセージが表示される。そこで、nanopi NEO2とchromecastの間のパケットをキャプチャーしてみたら、不思議なことが起きていた。

chomecastとのパケット
TXTを要求しているのに、chromecastからの応答はSRVになっている。それと、chromecastは応答メッセージ中のtransaction IDも正しくセットしていないのではないか?
chromecastのファームウェアは自動で更新されるし、googleはリリースノートも出していないようなので、いつこのような変更が起きたのかは全くわからないが、今年の1月ぐらいに確認したときには、このような問題はなかったので、それ以降のどこかでだろう。こんな単純なミスが見逃されているとは。Net::Bonjourがメンテされていなくて、無理無理マルチキャストに対応させたのだが、根本的に作り直さないと、現行のchromecastのファームウェアでは正しく、デバイスの名前が検出できない。このTXTに対してSRVを返信する問題をgoogleは直してくれるのだろうか?

Perlでメモリリーク?

多分2016年の12月ぐらいからPOPFileを使っていて、今まで特に運用上の問題はなかった。最近ふと気づいたのだが、どんな単語が登録されているのか見てみたら、文字化けしているものや、意味のない英数字の羅列なども登録されていて、これをきれいにする方法はないかと色々検索してみた。そのものずばりのツールはなかった。ただし、はてなダイアリーに以下のエントリーがあり、この方法でも一部は削除できるだろうと思って試してみた。

b.hatena.ne.jp

popfileを終了し、popfile.dbのコピーを取り、sqlite3のコマンドを実行し、popfileを再起動した。特にエラーもなく立ち上がり、その後メールの分類もしていたので、問題はないだろうと思っていたのだが、いつのまにかメールの分類が止まっており、web UIからアクセスすると、popfileが停止しているようだった。
/var/log/messagesを見ると、

swap_pager_getswapspace(12): failed

のようなウォーニングが大量に出ていて、最終的にはswapが枯渇して、終了していた。これはpopfile.dbが壊れたのかと思い、バックアップしておいたものに差し替えて再起動してみたが、それでも同じようにswapが枯渇する。FreeBSDに移行する前も、移行した後も特に問題なく動いていたと思っていたのだが、いったい何が起きているのはわけがわからなくなってしまった。でもswapinfoでswapの残り状況を見てみると、結構な速度で少なくなっていっている。それで、一分毎にswapinfoとtopで表示される、SIZEとRESの値をファイルに書き出して、調べてみた。

f:id:prozorec:20190318115945p:plain
メモリ使用状況

水色のSIZEの縦軸は右側の目盛りになるのだが、2時間ぐらいで61Mから675Mになり、SWAPの使用量はは12%から45%になった。これはどう考えてもperl内でメモリーリークが起きているのでは?だが、なんでpopfile.dbを編集するまで気づかなかったのだろう?ログインして、手動で起動したときだけこの問題が発生しているような気がする。となると、何らかの環境変数が影響しているのだろうか?

それで、環境変数をunsetしながら試してみると

LANG=ja_JP.UTF-8

が設定されていると、モリモリとメモリを消費するように見える。LANGをunsetして起動した場合は、こんな感じになる。

f:id:prozorec:20190318120911p:plain
メモリ使用量2

8時間ほど動かしてもさほど上昇しない。ただ、全く上昇しないわけではなく少しは増えているので、やっぱり漏れているのだろうか?よく判らない。

ちなみにFreeBSD 12のperlはv5.28.1で最新のはず。