エディタを使っている場合、エディタを操作するのは簡単です。 ファイルを開く、などと動かせばよいのです。 このように操作できるのは、エディタにそういった機能があり、 かつエディタが端末に関連づけられているからです。 一方、ユーザから始終入力があるように設計されていないプログラムもあり、 そういったプログラムは最初から端末と切り離されます。 例えば、ウェブサーバは一日中ウェブのリクエストばかり処理するので、 通常全く入力を必要としません。 サイトからサイトへとメールを転送するプログラムも、 こういった種類のアプリケーションの一例です。
このようなプログラムは、デーモンと呼ばれます。 デーモンはギリシャ神話の登場人物で、 善でも悪でもなく、大雑把にいうと、 人間のために役立つことをしてくれる小さな妖精さんです。 今日の便利なウェブサーバやメールサーバととてもよく似ていますね。 このため、長い間 BSD のマスコットはスニーカーをはいてフォークを携えた かわいらしい姿のデーモンなのです。
通常デーモンとして動作するプログラムには末尾に “d” を持った名前をつける慣習があります。 BIND は Berkeley Internet Name Daemon ですし (実際実行されるプログラムは named という名前です)、 Apache ウェブサーバのプログラムは httpd と呼ばれますし、 ラインプリンタスプーリングデーモンは lpd、 などなどです。 これは単なる慣習で、しっかりがっちりとしたルールではありません。 例えば、Sendmail アプリケーションの主なメールデーモンは sendmail という名前で、 連想しそうな maild ではありません。
時々、デーモンプロセスと通信したいときがあります。 この通信はシグナルと呼ばれ、 デーモンにシグナルを送ることによってデーモン (に限らずどんな動作中のプロセスでも)と通信することができます。 送信可能なシグナルはたくさんあります--特別な意味があるものもあれば、 アプリケーションによって解釈されるものもありますし、 アプリケーションがシグナルをどう解釈するかは そのアプリケーションの文章を読めば分かるでしょう。 自分が持っているプロセスにしかシグナルを送ることはできません。 他人のプロセスに kill(1) や kill(2) を使ってシグナルを送っても、許可されないでしょう。 これの例外は root ユーザで、 ルートユーザは誰のプロセスでもシグナルを送ることができます。
FreeBSD もアプリケーションにシグナルを送ることがあります。 アプリケーションを下手に書くと、 予想外のメモリにアクセスしようとするので、 FreeBSD がプロセスに セグメンテーション違反 シグナル (SIGSEGV) を送ります。 ある程度の時間が経ったら alarm(3) システムコールを使って警告してもらうようなアプリケーションには、 警告シグナル (SIGALRM) が送信される、 などです。
プロセスを止めるためには2つのシグナル、 SIGTERM か SIGKILL を使います。 SIGTERM は穏かにプロセスを終了させる方法です。 プロセスはシグナルを受け取ることができ、 終了させたいのだなということを理解し、 開いているログファイルを全部を閉じ、 一般的に終了前にしていたことを終えることができます。 中断できない処理の途中だと、SIGTERM をプロセスが無視することもあるかもしれません。
プロセスは SIGKILL を無視することができません。 これは、“なにをしていようが構わないから今すぐ止まれ” というシグナルです。 プロセスに SIGKILL を送ると、 FreeBSD はそのプロセスをそこで止めます[1]。
使う可能性のあるシグナルは、他に SIGHUP、SIGUSR1、と SIGUSR2 があります。 これらは一般的な用途のシグナルで、 このシグナルが送信されたときアプリケーションによって別のことをします。
ウェブサーバの設定ファイルを変更したとしましょう--ウェブサーバに新しい設定を再読み込みさせたいですね。 httpd を止めて再起動することもできますが、 そうするとウェブサーバは一瞬ながら停止してしまいますし、 ちょっとでも止まってほしくないこともあるでしょう。 ほとんどのデーモンは SIGHUP シグナルに対して設定ファイルを再読み込みする反応を返すよう書かれています。 従って、httpd を止めて再起動する代わりに、 SIGHUP シグナルを送りましょう。 これらのシグナルへの標準的な反応というものがないために、 デーモンごとに行動が違うので、 疑問があれば必ずそのデーモンの文書を読んでください。
kill(1) コマンドを使って送るシグナルはこの例をご覧ください。
プロセスにシグナルを送る
この例では、inetd(8) にシグナルを送る方法を示します。 inetd(8) の設定ファイルは /etc/inetd.conf で、 inetd(8) は SIGHUP が送信されるとこの設定ファイルを再読み込みします。
シグナルを送りたいプロセスのプロセス ID を探します。 それには ps(1) と grep(1) を使います。 grep(1)
コマンドは出力を検索するために使い、 指定した文字列を探します。
このコマンドは一般ユーザで実行しますが、 inetd(8) は root
で実行されているので、 ps(1) には ax
オプションを与える必要があります。
% ps -ax | grep inetd 198 ?? IWs 0:00.00 inetd -wW
ということで、inetd(8) の PID は 198 です。 grep inetd コマンドがこの出力に出てくる場合もあります。 それは、ps(1) が動作中のプロセスのリストを見つける方法によります。
kill(1) を使ってシグナルを送ります。 inetd(8) は root で起動されているために、 まず su(1) を使って root にならなければなりません。
% su Password: # /bin/kill -s HUP 198
大部分の Unix コマンドと同じく、 成功したら kill(1) は何の出力も表示しません。 自分のものではないプロセスにシグナルを送ると、 “kill: PID: Operation not permitted” と表示されます。 PID を打ち間違えると、 悪いことに間違ったプロセスにシグナルを送ってしまうか、 もしくは運がよければその時点で使われていない PID にシグナルを送ったことになり、“kill: PID: No such process” と表示されます。
なぜ /bin/kill を使うんでしょう?: 多くのシェルは kill コマンドを組み込みコマンドとして備えています。 つまり、/bin/kill を実行するのではなく、 シェルが直接シグナルを送ります。 これはとても便利なのですが、 シェルが違うと送るシグナルの名前の指定の仕方が違います。 シェルによって異なるシグナルの指定の仕方を全部覚えようとはせずに、 /bin/kill ... コマンドを直接使うほうが簡単です。
他のシグナルの送り方はほとんど同じで、 コマンドラインの TERM や KILL を必要に応じて変えるだけです。
Important: システム上のランダムプロセスを終了させるのはよくありません。 特に、プロセス ID が 1 の init(8) は特別です。 /bin/kill -s KILL 1 を使うといとも簡単にシステムをシャットダウンさせることができます。 Return を押す前に kill(1) を実行する引数を二重にチェックする癖をつけてください。
| [1] |
正確ではありません--中断できないものはわずかながら存在します。 例えば、プロセスがネットワーク上の別の計算機にあるファイルを読もうとして、 その計算機がなんらかの理由 (電源を落とされたとか、ネットワークに問題があるとか) でいなくなった場合、そのプロセスは“中断不可能”と言われます。 最終的にはそのプロセスはタイムアウトします。普通は2分後です。 タイムアウトした直後、そのプロセスは終了します。 |