Q&A
>tsharkのキャプチャ数(データ量) これは64KB以上でしょうか? Popen.communicateで、Hangしている可能性もあるのでは。
以下のサイトにあるmypool.pyを使い並列処理を実装しています。
http://d.hatena.ne.jp/halhorn/20100904/1283612722
処理内容としては、子プロセス(multiprocessing.Process)として、
tshark(wiresharkのCUI版)を起動し、
そのキャプチャ結果をmultiprocessing.Pipeで受け取るものです。
理由があり、終了待ちをしないといけないため、
multiprocessing.Process.joinで終了待ちをしています。
ところが、tsharkのキャプチャ数(データ量)が多くなると、
このjoinが終了しなくなります。(少ない場合はjoinは終了します)
joinの前に行っているPipe経由のrecv関数までは正常に処理できています。
送受信バッファの問題かなと考えましたが、recv関数後にpollを呼んでも
0が返る(受信すべきデータがない)ため原因がわかりません。
抽象的な文面で分かりにくくて申し訳ありませんが、
お気づきの点があり、アドバイスを頂けると助かります。
よろしくお願いします。
以上です。
コメントありがとうございます。64KBを超えた場合、Popen.communicateは使えないということでしょうか？その場合、どのような処理に置き換えれば回避できるでしょうか？
いえ、普通にstdoutとstderrにファイルオブジェクト)tempfile.TemporaryFileやuniqueな名前）を渡せばよいのでは。10年前の記事ですが、https://thraxil.org/users/anders/posts/2008/03/13/Subprocess-Hanging-PIPE-is-your-enemy/ この問題だとするならば、最初にも提起しましたが、止まる正確なバイト数を特定する所からではないでしょうか。
参考サイトありがとうございます。この対処と hayataka2049 さんに教えて頂いた対処でうまく行けそうな気がしてます。結果は別途報告させて頂きます！
回答1件
0
ベストアンサー
安直ですが、とりあえずほしい結果が得られていて、I/O等のリソース等も触っていないのであれば、強制的に殺してしまっても良いのではないでしょうか。
joinの引数に整数を入れると、タイムアウトさせられます。
投稿2018/06/13 14:03
総合スコア30939
コメントありがとうございます！
joinの引数にtimeoutを指定し、そのあとにis_alive()がtrueであれば、
terminate()をするようにしたのですが、その時のデータの内容を確認すると、データが途中までしか引き取れてません。なんか詰まっているのかデッドロックになっているような感じです。
困りましたね（汗）どうしましょうか。それなりに色々調べてみないとよくわからないかも
とりあえずプログラムは載せてみて頂けますか。ここでデータがヘンでしたみたいなコメントも入れていただけると助かります
ありがとうございます。
掲載のURLページに載っているmypool.pyを使っているコードが、版権問題で提示できないため、問題を整理して再度追加の情報を提示致します。
あの後、こちらでも調べているのですが、親プロセスと子プロセスのデータの受け渡しにmultiprocessing.Queueを使っているのですが、これが大量データのときと少量データ(うまくいくケース)で、挙動が違ってそうで、その辺りを調べています。どちらもQueueのデフォルトMAXサイズの1024は超えていないのは確認しています。
そうですか。リンク先のコードをもう一回読み直してみましたが、これに引っかかってる可能性を考えるべきかも
＞オブジェクトは pickle でシリアライズ可能でなければなりません。 pickle が極端に大きすぎる (OS にも依りますが、およそ 32 MB+) と、 ValueError 例外が送出されることがあります。
https://docs.python.jp/3/library/multiprocessing.html#multiprocessing.Connection.send
でも別に例外が出てる訳じゃないのか・・・なんだろう？
ありがとうございます。
キャプチャした情報をキューに入れて、それを配列にしたときにキューの数と合わない時があります。キャプチャした文字列に制御コードが入っているのかもしれませんので、ご指摘のシリアライズ化は的確かもしれません。明日試してみます！
プロセス間のデータの受け渡しに使っているmultiprocessing.Queueは、
put/getでpickle化を叩いているようです。
putするオブジェクトは辞書型でこれもpickle対応のオブジェクト型でした。
pickle自体は大きくても基本的に問題なく動くはずなんですけどねぇ。何か怪しいことになってるとしか
それを使うのをやめて、multiprocessing.Poolで書き直す訳にはいきませんか？ なんかこんな感じでできるらしいですけど
http://aflc.hatenablog.com/entry/20110825/1314366131
multiprocessing.Poolのご提案ありがとうございます。
実装に関してはマルチプロセス(スレッドはNG)で実現できれば方法は問いませんので、ご提示のURLを参考にお試し実装してみます。
ありがとうございます。
そもそもトップレベル関数で書ければ、何もしなくてもPoolでできるのですが、それは無理ですか？（コード見ないと判断できないなやっぱり・・・）
あとは、疑うべきはmultiprocessingの他にもtsharkがあった・・・軽く見落としていましたが、コマンドライン引数などの設定が適切でないとけっこうシビアに情報が捨てられるのでは？
明日、加工したソースを掲載します。
(色々関係ないところを削ったりする必要があるため少し時間が掛かります)
その時、お手すきであればみて頂けると大変助かります。
tsharkに関しては、プログラムで実行している引数で、コマンドラインで実行しましたが、特に問題が見られませんでした。(無線のキャプチャを行っています)
tshark -i wXXXX -n -t ad -I -Y 'wlan.fc.type_subtype eq 4 || wlan.fc.type_subtype eq 5 || wlan.fc.type_subtype eq 8' -T fields -E separator=";" -e _ws.col.Time -e radiotap.channel.freq -e radiotap.dbm_antsignal -e wlan.sa -e wlan.da -e _ws.col.Info -e wlan.ht.capabilities -e wlan.tag.length -e wlan.supported_rates -e wlan.extended_supported_rates -e wlan.tag.oui -e wps.manufacturer -e wps.model_name -e wps.model_number -e wps.uuid_e -a duration:10
取れる内容は以下のような感じで最大で500件程度取得できています。
{'fp': ';0,8,1,4,6,1,4,24,9;130,132,139,150,12,18,24,36;48,72,96,108;20722,895;;;;', 'sensorunit': 2, 'dbm': -75.0, 'ssid': 'XXXXX', 'subtype': 'Beacon frame', 'mac': 'XX:XX:XX:XX:XX:XX', 'flags': '........C', 'sn': 524, 'observationtime': '2018-06-14 11:49:02.126062+09:00', 'host': 'XXXXX', 'freq': 2412.0}
ひとこと。コメント欄はmarkdownが効かないので、質問文に追記してくださいな。あとどうしようもなく長いコメントになっちゃったので、再編集して適当に消しといてください（みづらい・・・
コードが最大文字数に達したため gistに張りつけました。
https://gist.github.com/spike0726/3857f1e4ab9611758054ef7c1bc21ab5
補足説明
このプログラムは常駐プログラムです。
リモートからPyhtonRPCで以下の順序で関数コールして、
tsharkのキャプチャデータを取得します。
setup()→ wlan_capture()→queue_get()
お時間あるときに見て頂けたらと思います。
あ、gistに貼ってくれたならそれで良いです（でもやっぱり余計なスクロールが増えるので、コメントは消しといて・・・
先ほどのコードのコメントは削除依頼を出しました。
またgistに張り付けたソースは部分的に抜粋しています。
よろしくお願いします。
削除依頼も良いんですが、コメントの上にマウスカーソルを持っていくと鉛筆マークが出てきて、それをクリックするとコメントを編集できます。それで全選択→全消しして、代わりに「削除済み」とでも書いておいてくださいな
コードをざっとは見ました。MyPool自体は手元で検証してみましたが、大きめなデータを投げても正常終了するので、これにはあまり問題はないのかもしれません。そうすると怪しいのはQueueですが、これですかね
https://docs.python.jp/2.7/library/multiprocessing.html#pipes-and-queues
＞警告 上述したように、もし子プロセスがキューへ要素を追加するなら (かつ JoinableQueue.cancel_join_thread を使用しないなら) そのプロセスはバッファーされたすべての要素がパイプへフラッシュされるまで終了しません。
＞これは、そのプロセスを join しようとする場合、キューに追加されたすべての要素が消費されたことが確実でないかぎり、デッドロックを発生させる可能性があることを意味します。似たような現象で、子プロセスが非デーモンプロセスの場合、親プロセスは終了時に非デーモンのすべての子プロセスを join しようとしてハングアップする可能性があります。
＞マネージャーを使用して作成されたキューではこの問題はありません。詳細は プログラミングガイドライン を参照してください。
細かく見て頂きありがとうございます。m(__)m
結論としては、今の実装を極力変えずに改修する場合は、
multiprocessing.Queue()ではなく
multiprocessing.manager().Queue()
にするとうまくいく、ということになるのでしょうか？
(現時点ではmultiprocessing.Queue()がほぼほぼ原因であろうと思っています)
そのまま書き換えて動くかはちょっとわかりませんが、方向性としてはmanagerを使う方向になるのかなと
おっしゃる通りですね。
managerの使い方をきちんと調べて正しい使い方で実装してみます。
ありがとうございます！
コードは、multiprocessing.Queue()をmultiprocessing.Manager().Queue()に修正するだけで済みました。それでなんとうまくいきました！もう何か月にも渡って調べていたので大変助かりました。ありがとうございます。
なお、gistに掲載したソースはあまり見せるのはよろしくないもので削除致します。
あなたの回答
tips
プレビュー
