Go言語で知るプロセス（3）
シグナルのハンドラを書く ここからは、実際にGo言語でシグナルを扱う方法を紹介します。 最初に注意点ですが、シグナルに関する設定はプロセス全体に及ぶグローバルな設定です。 また、シグナルはフォアグラウンドのプロセスに最初に送信されます。 したがって、自作のコードでシグナルのハンドラを書き、それをgo runを使って実行すると、シグナルは自作コードのプロセスではなくgoコマンドのプロセスに送信されてしまいます。 これを避けるため、シグナルをハンドルするコードはgo runでは実行せず、go buildコマンドで実行ファイルを作成してから実行してください。 手始めに、SIGINTとSIGTERMを受け取ってもすぐには終了せず、それぞれSIGINT、SIGTERMと表示するコードを下記に示します。 package main import ( "fmt" "os" "os/signal" "sys
Linux シグナルの基礎
TLPI (The Linux Programming Interface) 再々。 TLPI の輪読の際に @matsumotory よりシグナルセットあたりをまとめるようにと指令が出たので、拙遅な感じでまとめました。 シグナルとは プロセス間通信の一種。「プロセスにシグナルを送信すると、そのプロセスの正常処理に割り込んで、シグナル固有の処理(シグナルハンドラ) が実行される」プロセス側では、シグナルを受信した際の動作(シグナルハンドラ) を設定することや、シグナルをブロックすることも可能。 コンソールで、プロセスを終了させるためにkill -9 <PID>とかCtrl+Cとかした際にも、対象プロセスにシグナルが送信されている。 ちなみに、PID「1」の init や systemd にkill -9 1しても何も起らない。(そういえば昔、oom-killer に init を殺された覚
Trapping signals in Docker containers
Have you ever stopped a Docker container? There are essentially two commands: `docker stop` and `docker kill` that can be used to stop it. Behind the scenes, `docker stop` stops a running container by sending it SIGTERM signal, let the main process process it, and after a grace period uses SIGKILL to terminate the application. Running applications in Docker, you could use signals to communicate wi
Linux シグナル入門 - 4. SIGHUP, SIGINT, SIGTERM
2013-11-5 (鈴) 1. シグナルとは？ 2. シグナル・ハンドラと signal システム・コール 3. シグナルの用途 4. SIGHUP, SIGINT, SIGTERM 5. SIGCHLD 6. SIGALRM と sigaction システム・コール 7. siglongjmp による大域脱出 8. popen/pclose と SIGCHLD Linux などの Unix 類ではプロセスを終了させる事象のうち，次の３種類のシグナルの発生は当然起こり得るものとして想定しなければならない。 SIGHUP (= 1, hangup) 端末終了時に発生。元来はモデムの受話器をあげて通信を切ったことから SIGINT (= 2, interrupt) Control-C による中断 SIGTERM (= 15, termination) kill コマンドでシグナル無指定時に送
signal – 非同期のシステムイベント通知を受け取る - Python Module of the Week
Note Unix シグナルハンドラでプログラミングすることは普通以上の努力が必要です。本稿はシグナルの入門です。全てのプラットホーム上で正しくシグナルを利用することの詳細は説明していません。Unix のバージョンを横断して標準仕様があり、また変形した仕様もあります。そのため、実行して問題があれば使用中の OS のドキュメントを調べてください。 シグナルはあるイベントをプログラムへ通知するオペレーティングシステムの機能で、非同期にその通知を受け取ります。シグナルはそのシステムが生成するか、1つのプロセスから他のプロセスへ送信されます。シグナルはプログラムの通常処理の流れを中断させるので、シグナルを受信したら何らかの操作(特に I/O)でエラーを発生させることができます。 シグナルは整数値で識別され、オペレーティングシステムの C 言語のヘッダに定義されています。Python は signa
-%25E3%2582%25B7%25E3%2582%25B9%25E3%2583%2586%25E3%2583%25A0%25E3%2582%25B3%25E3%2583%25BC%25E3%2583%25AB%25E5%2586%258D%25E5%25AE%259F%25E8%25A1%258C(sleep))
シグナル(その4)-システムコール再実行(sleep) - Linuxの備忘録とか・・・(目次へ）
システムコールで待機中にシグナル配信処理が行われると、そのプロセスは起床され（TASK_RUN状態）、シグナル処理が動作する様なっていました。そして待機中だったシステムコールは、システムコールの返り値により、シグナル処理後再実行等の処理が行われるようになっていました。返り値とは、ERESTARTNOHAND/ERESTARTSYS/ERESTARTNOINTR/ERESTART_RESTARTBLOCK です。シグナル(その3)時の理解では、この値は該当システムコール自身が設定するものと理解しましたが、ついでと言うことで調べるて見ました。 ERESTART_RESTARTBLOCKについては、スリープで待機した時間を考慮して、再実行するものでした。ということでシステムコールsleep内で、ERESTART_RESTARTBLOCKがどのように設定されるかを見てみようと思います。 スリープは
memologue - シグナルハンドラを使わないでシグナルをハンドルする
「シグナルハンドラの中でできることは非常に限られているんですよ」というお話を1年半くらい前に書きましたが、この話には続きがあって、ある特定の条件下ではこの制限を緩和することができます。今回はその方法についての解説です。sigwait(3)という関数を使います。 ※ この話、うっかり書き忘れていました。ちょっとしたきっかけで思い出したので、暇があるうちに書いておきます。 ■「シグナルを待つ」処理 〜従来の方法〜 皆様、「シグナルの到着を待つ」処理を、次のように書いてしまっていないでしょうか？ // シグナルハンドラ void handler(int signo) { // この中で使って良いのは非同期シグナルセーフ(async-signal-safe)な関数のみ }を用意して、 sa.sa_handler = handler; sigaction(SIGHUP, &sa, NULL); ..
第6回 UNIXプログラミングの勘所（3） | gihyo.jp
ネットワークプログラムとSIGPIPE 「私の書いたサーバが突然死するんです。どうしてでしょうか」という質問を受けることがあります。これは多くの場合、SIGPIPEの処理を忘れていることが原因です。SIGPIPEとは、切断されたネットワークソケットなどにデータを書き込もうとした際に送出されるUNIXシグナルです。特に設定しない限り、プロセスはSIGPIPEを受け取ると強制終了されます。そのため、通信が突然切断される可能性のあるTCPサーバにおいては、SIGPIPEを無視するよう設定する必要があります。 # デフォルトの動作（SIGPIPEの場合はプロセスの終了）に設定 $SIG{PIPE} = 'DEFAULT'; # SIGPIPEを無視するよう設定 $SIG{PIPE} = 'IGNORE'; # SIGPIPEを受信した際に実行するサブルーチンリファレンスを # 設定 $SIG{PI
bash で Ctrl-C をフックする方法 - pyopyopyo - Linuxとかプログラミングの覚え書き -
bash で Ctrl-C をフックする方法、つまりSIGINTを自前のシグナルハンドラで捕捉する方法についてメモ。 概要 シグナルハンドラを設定するには、trap というbashのビルトイン・コマンドを使います #!/bin/bash hander() { echo "recv!!" } trap hander SIGINT while /bin/true; do : ; done Ctrl-Cを押すと SIGINT という名前のシグナルがプロセスに通知されるので、trapコマンドで SIGINT を受け取ったら hander という関数を呼ぶように設定しています このシェルスクリプトは実行すると末尾で無限ループになるだけです。ただCtrl-C を押しても、シェルスクリプトは終了せず、代わりに hander()関数が呼ばれて"recv!" という文字列が画面に表示されます Ctrl-Cで
Ctrl+Cとkill -SIGINTの違いからLinuxプロセスグループを理解する | ギークを目指して
しばらくLinuxネタが続く・・。 近いうちに最近出たJava8ネタを書いてみようと思います。が、もう少しLinuxネタにお付き合いください。 前回はsshdを対象に親プロセスをkillした場合の動作を確認した。 killされたプロセスの子プロセスは孤児プロセスとなり、カーネルによって自動的にinitプロセスの子として扱われる事を説明した。（この動作を「リペアレンティング」と呼ぶ） 今回はこの続き。 Linuxで作業していてCtrl+Cしてプロセスを終了した場合、フォアグラウンドのプロセスやその子プロセスも一緒に終了する。 ということは、子プロセスは孤児として扱われず、リペアレンティングされていないことになる。 今回の記事ではこの振る舞いの違い（リペアレンティングされるか否か）に着目し、kill -SIGINTコマンドとCtrl+Cの違いについて考えていく。 そもそもkillコマンドやCt
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.gembook.org/2011-03-28.html