|
>ただし、SIGKILL と SIGSTOP >だけは無視できません (ハンドラの設定も不可)。 横からすみませんが、無視できずハンドラの設定不可な シグナルは、どのような意味があるのでしょうか？ (なぜ送られてくるのでしょうか？) |
|
>>1888 dio > 無視できずハンドラの設定不可なシグナルは、 > どのような意味があるのでしょうか？ シグナルをブロックしたプログラムが誤って無限ループしてしまったら 止める術がなくなります。 なので、プロセス側から制御できない SIGKILL や SIGSTOP という シグナルを飛ばすことで、OS に強制的にプロセスを殺したり、動作を 止めたりするわけです。例をあげると、 #!/usr/bin/perl $SIG{TERM} = sub { print "TERM!\n" }; # kill コマンド対策 $SIG{INT} = sub { print "INT!\n" }; # Ctrl-C 対策 while (1){ printf("%d\n", $i++); sleep 1; } というプログラムを実行すると、Ctrl-C や kill プロセス番号 で 終了させることはできません。しかし Ctrl-Z で動作を止めたり、 kill -9 (＝kill -KILL) でプロセスを殺すことはできます。 # 実際は他にもシグナルはありますので、kill -HUP などで # 殺すことが可能ですが、全てプログラム側でブロック可能です。 なお、SIGINT や SIGTERM を受けると、ファイルなどの後始末を 行ってから終了するプログラムは多いです。なので、いきなり SIGKILL で強制終了させるのはおすすめできません。まず SIGTERM や SIGINT を試して、それでも死ななければ SIGKILL を使うように して下さい。 |
|
えーと、私は何か勘違いをしていたかもしれません； >なので、プロセス側から制御できない SIGKILL や SIGSTOP という >シグナルを飛ばすことで、OS に強制的にプロセスを殺したり、動作を >止めたりするわけです。 これはわかります。SIGKILL、SIGSTOPの必要性はわかるのですが、 プロセスから制御できない物をなぜシグナルとして送る 必要があるのだろうかと思ったのです。 私はOSがプロセスにSIGKILL や SIGSTOPをとりあえず送って、 強制終了させる物と思っていたのですが、この考えが方が間違いでしょうか？ |
|
>>1890 dio ん〜、SIGKILL, SIGSTOP の必要性はわかるが、ブロックできないんだから 「シグナル」として扱うのは変ではないか。SIGKILL, SIGSTOP と同等の 機能を持たせたシステムコールを新設した方がよいのではないか、という ことでしょうか? じゃなくて、OS が SIGKILL や SIGSTOP を送るのはわかるが、 コマンドラインで kill コマンドを使って SIGKILL, SIGSTOP を 送れるのは変ではないか、ということですか? |
|
前者のほうにちかいです プロセスを殺すのはOSなのですよね？ プロセスにSIGKILLやSIGSTOPが送られても プロセスはそれに対して何も出来ないのなら、 なぜ送られてくるのかな？と。 プロセスはSIGKILLやSIGSTOPを認識出来ないのではないのですか？ |
|
>>1892 dio > プロセスはSIGKILLやSIGSTOPを認識出来ないのではないのですか？ できないです。 OS はプロセスごとにシグナルのテーブルを保持しています。例えば SIGTERM を無視する場合はテーブルの SIGTERM の項目を 1 に、 シグナルハンドラをセットする場合は、SIGTERM の項目にシグナル ハンドラ (関数) のアドレスをセットする、というふうに。 で、シグナルが飛んできたら、OS は対象のプロセスのテーブルを 参照し、無視すべきか、ハンドラを実行すべきかなどを決めます。 しかし SIGKILL/SIGSTOP は、 - テーブルの書き換えができない - シグナル発生時に OS がテーブルを参照することなくプロセスを操作する のどちらかの理由のため (どっちが本当かは知りません)、プロセス からブロックすることはできません。 だから、実際に OS が何かをプロセスに送っているわけではありません。 …で、回答になりましたか? ちなみにシグナルは FreeBSD なら ここらへんで処理してます。 http://www.jp.FreeBSD.org/cgi/cvsweb.cgi/src/sys/kern/kern_sig.c?rev=1.115 |
|
>で、シグナルが飛んできたら、OS は対象のプロセスのテーブルを >参照し、無視すべきか、ハンドラを実行すべきかなどを決めます。 なるほど、シグナルを受け取るのはOSなんですか。 >だから、実際に OS が何かをプロセスに送っているわけではありません。 そうでしたか。 私の考え方がWindows的でした。 (WindowsのMessageのような物と考えてました;) >…で、回答になりましたか? はい、どうもありがとうございました。 |
|
>>1884 68user >それは、問題のマシンで > % telnet localhost >でログインできないということですね? お返事が遅くなってしまいました。すみません。 上記のように入力すると、 SunOS5.6 ....(省略）普通といっしょ。 connection closed by foreign host. といわれます。 UNIXの相当詳しい人に見てもらったのですが、ぜんぜんおかしい 部分がないとのことでした。 来週OSをインストールしなおすとその方がおっしゃっておりました。 ご迷惑をおかけしました。 また分からないことがありましたらよろしくお願いします。 |
|
初めまして。 現在文字コードの変換について色々と模索中です。で、 このページの過去ログを見つけたのですが、情報を うまく理解することができなかったので質問させて ください。 まずバックグラウンドとして、Solaris2.6のWebサーバを 今まで他の人が管理してきたものの引継ぎで管理する事 になったのですが、そのWebサーバは文字の変換に /bin/iconvを利用しています。htmlファイルはeucJPで かかれていました。さらにソースの中でMETAタグに 「charset=x-euc-jp」という記述がありました。 またユーザからの情報をCGIからOracle(Solaris2.6上)に データを格納しています。この際CGIではeucからUTF-8に 変換を行なう記述がなされています。 # DBは個人的に触ることができない状態です。Solaris2.6 # の/bin/iconvを利用するところも変えられません。 通常インターネットを意識した時にはWindows環境(もち ろんこの中にも色々ありますが)だけを意識するのではなく、 色々な環境を意識してhtmlファイルを書くべきなのだと 思うのです(私見?)。 前置きが長くなりましたが質問です。 １．ソースの中でMETAタグに「charset=x-euc-jp」という 記述がある場合、ブラウザのエンコードで「自動認識」を 指定していれば、ソースは読める状態で表示され、かつ フォームに入力した文字列はeucJPでWebサーバに送信されて くるものだと信じているのですが正しいのでしょうか。 ２．また正しい場合、表示を強引にSJISなどにしてフォーム に入力した場合にはeucJPで送られてくるのでしょうか。 それともSJISなのでしょうか。(まだ環境を自由にできない ので自分では確認できません。) ３．半角が入力されてきた場合にはどのように対処すれば いいのでしょうか。 ４．JIS X 0208の13区、89〜92区、115区〜119区(換算)の 文字を入力するとエラーで返すようにしたいのですが、CGI でどのように記述すればいいのでしょうか。EUCコードで ADA1〜ADFE、F9A1〜F9FE、FAA1〜FAFE、FBA1〜FBFE、FCA1〜 FCFE(全て16進数) は不可、のように文字コードそのもので 制限をかけるのでしょうか。Perlでこういった内容を書き たいのですが、何か参考になるようなものがありましたら お知らせください。 長い文章になりましたが、ご助力お願いいたします。 |