うーむ、面妖な
Hideo Sir MaNMOS Morishita
森下 お代官様 ＭａＮＭＯＳです。
親プロセスと子プロセスがあるプログラムで、子プロセスを生成後、親プロセ
スでエラーを発見して、子プロセスにSIGTERMを送って自分は終了するってプ
ログラムで、なぜか子供が死なない。
で、gdbでアタッチしてみると、なんと、forkの最中でsignalハンドラに入っ
て、その中のsyslog(正確にはvsyslog)でブロックされてしまって止っている。
これって、LINUXでは当たり前なんですか？
ちなみにdistributionはRedhat、カーネルバージョンはkernel-2.4.20-20.9で
す。
＃signalはく前にsleepしました。不細工。
--
___ わしは、山吹色のかすてーらが大好きでのぅ
[[o o]] ふぉっふぉっふぉ
'J' 森下 お代官様 ＭａＮＭＯＳ 英夫＠ステラクラフト
PGP Finger = CD EA D5 A8 AD B2 FE 7D 02 74 87 52 7C B7 39 37
Shinji KONO
In article <squ7k4q...@stellar.co.jp>, man...@stellar.co.jp (Hideo "Sir MaNMOS" Morishita) writes
> で、gdbでアタッチしてみると、なんと、forkの最中でsignalハンドラに入っ
> て、その中のsyslog(正確にはvsyslog)でブロックされてしまって止っている。
(そういう時に使うのか...)
何で止まるのかはわからないんですけど..
> 親プロセスと子プロセスがあるプログラムで、子プロセスを生成後、親プロセ
> スでエラーを発見して、子プロセスにSIGTERMを送って自分は終了するってプ
> ログラムで、なぜか子供が死なない。
なんかありがちですよね。pipe でつなげて子供に自殺させる命令
を送るなんてのをやってました。
---
Shinji KONO @ Information Engineering, University of the Ryukyus,
PRESTO, Japan Science and Technology Corporation
河野真治 @ 琉球大学工学部情報工学科,
科学技術振興事業団さきがけ研究21(機能と構成)
北條武志
勘違いがありましたらすいません。
"Hideo "Sir MaNMOS" Morishita" <man...@stellar.co.jp> wrote in message
news:squ7k4q...@stellar.co.jp...
>
> 親プロセスと子プロセスがあるプログラムで、子プロセスを生成後、親プロセ
> スでエラーを発見して、子プロセスにSIGTERMを送って自分は終了するってプ
> ログラムで、なぜか子供が死なない。
>
この流れだと、子プロセスにSIGTERMを送った後、子プロセスから
のSIGCHILD受けてから、親が死ぬようにしないと、子はゾンビに
なる気がするのですが、どうでしょう？ちがったらすいません。
> で、gdbでアタッチしてみると、なんと、forkの最中でsignalハンドラに入っ
> て、その中のsyslog(正確にはvsyslog)でブロックされてしまって止っている。
>
これは、ｇｄｂのオプションで、子プロセスも追跡するように設定
しとかないと、親が子を作ったところまでで止まって見えるという
はなしではないでしょうか？もしくは、親プロセスから、子プロセス
に対象の切り替えをしてなかったとか。
以上、よろしくおねがいいたします
Hideo Sir MaNMOS Morishita
In article <AYx6b.55$SG6...@news1.dion.ne.jp>,
"=?iso-2022-jp?B?GyRCS0xbaklwO1YbKEI=?=" <ta...@m6.dion.ne.jp> writes:
> "Hideo "Sir MaNMOS" Morishita" <man...@stellar.co.jp> wrote in message
> news:squ7k4q...@stellar.co.jp...
> >
> > 親プロセスと子プロセスがあるプログラムで、子プロセスを生成後、親プロセ
> > スでエラーを発見して、子プロセスにSIGTERMを送って自分は終了するってプ
> > ログラムで、なぜか子供が死なない。
> >
> この流れだと、子プロセスにSIGTERMを送った後、子プロセスから
> のSIGCHILD受けてから、親が死ぬようにしないと、子はゾンビに
> なる気がするのですが、どうでしょう？ちがったらすいません。
違います。子供はorphanになるので、initが看取ってくれます。そうでなかっ
たらdaemonは全部zombieに…(unix屋でない人が聞いたら、何て恐ろしい会話)
あと、SYS V系だとSIGCHLDをignoreしておくとwaitする必要はないのです。た
しか、LINUXもそうですよね。
> > で、gdbでアタッチしてみると、なんと、forkの最中でsignalハンドラに入っ
> > て、その中のsyslog(正確にはvsyslog)でブロックされてしまって止っている。
> >
> これは、ｇｄｂのオプションで、子プロセスも追跡するように設定
> しとかないと、親が子を作ったところまでで止まって見えるという
> はなしではないでしょうか？もしくは、親プロセスから、子プロセス
> に対象の切り替えをしてなかったとか。
gdbのマニュアルのattachの項、または、起動オプションの項を読んでみてく
ださい。動作中のプログラムを取っ捕まえる方法が載っています。
＃SunONE Studioを手にいれてみましたがdbxもattachできるようになったんで
＃すね。
MAEDA Atusi
> で、gdbでアタッチしてみると、なんと、forkの最中でsignalハンドラに入っ
> て、その中のsyslog(正確にはvsyslog)でブロックされてしまって止っている。
>
> これって、LINUXでは当たり前なんですか？
Unixの規格だと，
> forkの最中でsignalハンドラに入って、
こっちは別におかしくないですが(1)，
> その中のsyslog(正確にはvsyslog)でブロックされてしまって止っている。
デッドロックしてるんですかね．こっちはおかしいです(2)．
(1) fork()はasync-signal-safe．だからre-entrantか *または* non-interruptible．
(Linuxではnon-interruptibleでないってことでしょう．)
(2) syslog()はasync-signal-safeでなくて「unsafeな関数がinterrupt され
た時，signal handlerからunsafeな関数を呼び出してはいけない
(undefined behavior)」が，今回のように「safeな関数がinterruptされ
た場合」には，ちゃんと動かないといけない．
http://www.opengroup.org/onlinepubs/007904975/functions/xsh_chap02_04.html
> ＃signalはく前にsleepしました。不細工。
fork()の間だけsignalをblockするという手もあるのでは．これも不細工ですが．
> あと、SYS V系だとSIGCHLDをignoreしておくとwaitする必要はないのです。た
> しか、LINUXもそうですよね。
X/Open System Interface Extensionをサポートしているシステムなら，おっ
しゃる通りの動作をするようです．
http://www.opengroup.org/onlinepubs/007904975/functions/exit.html
前田敦司