Linux プロセス デーモン

目次

• プロセス
• ジョブ
• タスク
• スレッド
• サービス / デーモン

プロセス

process

メモリ上に展開され、実行されている状態のプログラム。

プロセスは、実行中のプログラムの基本単位であり、それぞれのプロセスは生成時にプロセスID（PID）が割り当てられる。

• カーネルは PID によってプロセスを識別し、メモリ、CPU、その他のリソースの割り当てを管理する
• 各プロセスは独立して動作し、基本的に他のプロセスとメモリ空間を共有しない
• 「ユーザが起動するプロセス」と、「システムが起動するプロセス（プロセスが起動する別のプロセス）」がある
• プロセスは起動したユーザの ユーザID（UID）と グループID（GID）を保持する

シェル もプロセスの一つであり、ビルトインシェル変数 $$ を確認することで、現在実行されているシェルのプロセスIDを知ることができる。

実行中のシェルのプロセス ID を確認する

$ echo $$

親プロセス / 子プロセス

プロセスには 親プロセス と 子プロセス という概念がある。

プロセスが fork() を呼び出すことで新しいプロセスが作成される。このとき、元のプロセスを 親プロセス 、新しく生成されたプロセスを 子プロセス という。

このように親プロセスから子プロセスを生成することを「fork する」と表現する。

ターミナルで実行したコマンドは、シェルによって起動されるため、シェルの 子プロセス* として扱われる

ゾンビプロセス

終了しているにも関わらず、プロセステーブルと呼ばれるカーネルのプロセス管理領域に情報が残ったままのプロセス。

名前の通り死んでいるけど完全には消えていない状態を指す。

通常、子プロセスが終了すると 終了ステータス やリソース情報（CPU、メモリ、ファイルディスクリプタ など）がカーネルに保存される。親プロセスは システムコール wait() や waitpid() を呼び出し、プロセステーブルから子プロセスの情報を削除する必要がある。

親プロセスが子プロセスの終了を認識できず、wait() や waitpid() を呼び出さない場合、カーネルはプロセステーブルの子プロセスの情報を消去することができず、ゾンビプロセスが発生する。

親プロセスが終了すると、ゾンビプロセスは init (または systemd) に引き取られ、自動的に wait() されて消える。そのため、ゾンビプロセスが残るのは親プロセスが生きている間だけとなる。

$ ps コマンドで確認すると、プロセスの状態（STAT）が Z、COMMAND が defunct で表示される。

ゾンビプロセス

$ ps aux
USER PID  %CPU %MEM VSZ    RSS  TTY STAT START   TIME COMMAND
user 1234 1.0  0.1  123456 7890 ?   Z    10:15   0:00 [my_program] <defunct>

$ ps aux | grep Z
user 1234 1.0  0.1  123456 7890 ?   Z    10:15   0:00 [my_program] <defunct>

ゾンビプロセスは、通常のプロセスとは異なりメモリやCPUを消費しないが、プロセステーブルのエントリを占有する。 そのため、ゾンビプロセスが大量に発生するとプロセステーブルの枯渇により新しいプロセスを作成できなくなる可能性がある。

プロセスグループ

複数のプロセスを OS がまとめて管理するための単位。

プロセスグループID（PGID）によって識別される。すべてのプロセスは PGID を保持している。

ジョブ の最初のプロセスの PID が PGID になることが多い。

プロセスグループを確認する（output format）

$ ps -o pid,pgid,comm 

シグナル はプロセスグループに対して送信することができる。

$ ps

Process Status

現在実行中のプロセスを表示する。

-u オプションで特定のユーザが起動したプロセスを表示することができる。

特定のユーザが起動したプロセスを表示する

$ ps -u ユーザー名

引数を省略すると、現在ログイン中のユーザが起動中のプロセス一覧が表示される。

ログインユーザが起動したプロセスを表示

$ ps

実行中のすべてのプロセスを表示するには ax もしくは -e オプションを使用する。

すべての実行中プロセスを表示（all:すべて、extra:端末に接続されていないプロセスを含む、every:すべて）

$ ps ax
$ ps -e

プロセスの詳細情報を確認する

$ ps -l

項目	意味
PID	プロセスID
TTY	プロセスが紐づく端末（TTY）
TIME	プロセスが CPU を使用した時間
CMD	実行中のシェルもしくはコマンド
PGID	プロセスグループ

$ top

プロセス情報、リソースの使用状況をリアルタイム表示する

$ top 

Q キーで終了。

それ以外のキーでインタラクティブモードに切り替えができる。

$ pstree

親子関係を含めて起動中のプロセスを表示する

$ pstree

$ pgrep

条件に合致したプロセスIDを表示する

$ pgrep 検索ワード

$ grep は 標準入力 やファイルから検索ワードを探すのに対して、$ pgrep は実行中のプロセスから検索ワードを探す。

正規表現 を使った検索が可能。

プロセスを起動したユーザを指定して検索を行う

$ pgrep -u ユーザ名 検索ワード

プロセスを起動したグループを指定した検索を行う

$ pgrep -g グループ名 検索ワード

$ nice

プロセスのスケジューリング優先度（priority）を変更してコマンドを実行する。

優先度は $ ps -l で確認することができる。

ただし、直接、優先度を変更するのではなく nice 値（ナイス値）を変更することにより相対的に変更する。nice値は -20 ~ 19 までの範囲で設定することができる（デフォルト値は 0）。

• nice 値が 高い → 優先度が 低い
• nice 値が 低い → 優先度が 高い

nice 値を +10 してコマンド実行する（デフォルトが +10）

$ nice コマンド

-n オプションにより、変更する nice 値を指定できる。

通常より低い優先度 (+10)で指定したコマンドを実行する

$ nice -n 10 コマンド

マイナス値は root ユーザのみ設定できる。

通常より高い優先度 (-5)で指定したコマンドを実行する

$ sudo nice -n -5 コマンド

$ renice

実行中のプロセスの nice 値を変更する。

指定したプロセスID（PID）の優先度を変更する

$ renice -n nice値 -p PID

nice 値を下げることができるのは root ユーザのみ。

$ kill

指定したプロセスを強制終了させる

$ kill プロセスID
$ kill プロセスID1 プロセスID2 ... # 複数指定可
$ kill %ジョブID
$ kill -プロセスグループID
$ kill -シグナル プロセスID
$ kill -シグナル番号 プロセスID
$ kill -s シグナル プロセスID

親プロセスを終了させた場合、子プロセスについても終了される。

コマンドの内部ではプロセスに対してシグナルが送信されている。以下のように直接シグナルを指定することもできる。

シグナルを明示的に指定する

$ kill -STOP プロセスID
$ kill -s STOP プロセスID

シグナルには数字が紐づいているため、数字を指定しても良い。

シグナルを数値で指定して実行

$ kill -19 プロセスID # 19:STOP

一般的に、プロセスの強制終了はリソースの解放よりも優先されるため、システムが異常を起こす可能性がある。そのため、先に $ kill -TERM プロセスID を実行して、それでも終了できない等、やむを得ない場合にのみ $ kill -KILL プロセスID を実行した方が良い。

シグナルを省略した場合は TERM シグナルを指定したことになる。

シグナルを省略した場合は TERM シグナルを指定したことになる

$ kill プロセスID
$ kill -TERM プロセスID # kill プロセスID と同じ

- を PGID の前につけることで、プロセスグループに対してシグナルを送信することもできる。

プロセスグループにシグナルを送信する

$ kill -TERM -プロセスグループID

シグナル

• プロセス → プロセス
• カーネル → プロセス

という方向の非同期通信の一つで、特定のイベントをプロセスに対して通知するための仕組み。

シグナルが送られると、プロセスは処理の途中であっても事前に定義された特定の動作を実行する。C 言語でこのシグナル受信時の処理をカスタマイズ実装することができるが、通常はデフォルトの動作が実行される。

またショートカットキー（Ctrl + C など）で送信されるシグナルは フォアグラウンドジョブ にのみ送信される。

シグナルの種類は $ kill -l で確認することができる。

シグナルを一覧表示する

$ kill -l
 1) SIGHUP	 2) SIGINT	 3) SIGQUIT	 4) SIGILL	 5) SIGTRAP
 6) SIGABRT	 7) SIGBUS	 8) SIGFPE	 9) SIGKILL	10) SIGUSR1
11) SIGSEGV	12) SIGUSR2	13) SIGPIPE	14) SIGALRM	15) SIGTERM
16) SIGSTKFLT	17) SIGCHLD	18) SIGCONT	19) SIGSTOP	20) SIGTSTP
21) SIGTTIN	22) SIGTTOU	23) SIGURG	24) SIGXCPU	25) SIGXFSZ
26) SIGVTALRM	27) SIGPROF	28) SIGWINCH	29) SIGIO	30) SIGPWR
31) SIGSYS	34) SIGRTMIN	35) SIGRTMIN+1	36) SIGRTMIN+2	37) SIGRTMIN+3
38) SIGRTMIN+4	39) SIGRTMIN+5	40) SIGRTMIN+6	41) SIGRTMIN+7	42) SIGRTMIN+8
43) SIGRTMIN+9	44) SIGRTMIN+10	45) SIGRTMIN+11	46) SIGRTMIN+12	47) SIGRTMIN+13
48) SIGRTMIN+14	49) SIGRTMIN+15	50) SIGRTMAX-14	51) SIGRTMAX-13	52) SIGRTMAX-12
53) SIGRTMAX-11	54) SIGRTMAX-10	55) SIGRTMAX-9	56) SIGRTMAX-8	57) SIGRTMAX-7
58) SIGRTMAX-6	59) SIGRTMAX-5	60) SIGRTMAX-4	61) SIGRTMAX-3	62) SIGRTMAX-2
63) SIGRTMAX-1	64) SIGRTMAX

シグナル番号	シグナル名	デフォルト動作
1	HUP	終了 / 再起動（Hang Up） シェルが起動している 端末（TTY）が閉じられると、シェルが HUP を受け取り、そのシェル内で実行中のプロセスにも HUP が送られ、デフォルト動作としてプロセスが終了する。設定ファイルの再読み込みに利用される。
2	INT	終了（Interrupt） Ctrl + C による割り込み
3	QUIT	コアダンプ Ctrl + \ によるプロセスの終了
9	KILL	強制終了 プロセスの即時終了 無視できない(※) リソースの解放を省略してプロセスが即時終了する
15	TERM	終了（Terminate） プロセスの正常終了 プロセス終了前にデータの保存、リソースの解放が行われる
18	CONT	再開（Continue） 一時停止中プロセスの再開
19	STOP	停止 強制的な一時停止 無視できない(※) 再開時は CONT シグナルが必要
20	TSTP	停止（Terminal Stop） Ctrl + Z シェルがプロセスをバックグラウンドへ移動させて停止させるが、$ fg や $ bg で再開できる

※無視できない=プロセスがこのシグナルをキャッチして処理することはできない

シグナル名はプレフィックス SIG 付きで定義されているが、省略形を使用できる。

$ kill -TERM プロセスID
$ kill -SIGTERM プロセスID

内部コマンド $ kill と 外部コマンドの $ kill

$ kill コマンドには以下の2種類が存在する。

• ビルトインコマンド（内部コマンド）としての $ kill
• 外部コマンドとしての $ kill

それぞれのコマンドは以下の違いを持つ。

• ビルトインコマンド
  • bash や zsh などのシェルに組み込まれたコマンド
  • シグナル送信先のジョブID（%ジョブID）を指定することができる
• 外部コマンド
  • 実行可能ファイル /bin/kill として存在するコマンド
  • シェルが持つジョブ管理機能とは連携しないため、ジョブIDを利用できない（ジョブはシェルが管理するプロセス）

$ type コマンドを使用すると、明示的に指定しない場合、どちらが利用されているかがわかる。

$ kill で使用されるのが内部コマンドか外部コマンドか調べる

$ type kill
$ kill is a shell builtin

外部コマンドを使用したい場合、絶対パスで実行する方法と $ command を利用する方法がある。

外部コマンドの $ kill を実行する

$ /bin/kill プロセスID
$ command kill プロセスID

$ killall

$ kill コマンドでは、シグナル送信先をプロセスID（PID）で指定できたのに対して、$ killall コマンドでは、プロセス名を使って指定することができる。

同じ名前のプロセスが複数存在する場合に便利（PID は重複しない）。

プロセスを kill する

$ killall -シグナル プロセス名
$ killall -s シグナル プロセス名

シグナルの指定については $ kill と同様で、省略した場合は TERM シグナルを指定したことになる。

シグナルを明示的に指定する

$ killall プロセス名
$ killall -TERM プロセス名 # killall プロセス名と同じ

プロセスを起動したユーザを指定する

$ killall -u ユーザ名

$ pkill

シグナルを送信するプロセスを「$ pgrep でヒットしたプロセス」のように指定することができる。

検索ワードにヒットするプロセスにシグナルを送信する

$ pkill -シグナル 検索ワード

シグナルの指定については $ kill と同様で、省略した場合は TERM シグナルを指定したことになる。

シグナルを明示的に指定する

$ pkill 検索ワード
$ pkill -TERM 検索ワード # pkill 検索ワード と同じ

プロセスを起動したユーザを指定する

$ pkill -u ユーザ名

ジョブ

一連の処理の単位。

単一または複数のプロセスで構成される。複数のコマンドを パイプ で実行した場合も、一連の処理が一つのジョブとされる。

シェル によって管理され、それぞれのジョブはジョブID（JID）で識別される。

JID はログイン中のシェルセッション内で 1 から順に割り振られるため、異なるシェルセッションでは同じ JID が使用されることもある。

JID を使用する際は、プロセスID（PID）と区別するために % が接頭語として使用される。

%ジョブID

$ kill %ジョブID
$ kill プロセスID

ジョブにはフォアグラウンドで実行されるものとバックグラウンドで実行されるものがある。

ジョブはシェルによって管理される

ジョブの実態

ジョブの実態は プロセスグループ であり、内部的にはプロセスグループとして扱われている。

プロセスグループは OS によって管理され、ジョブはシェルによって管理される。

ジョブID（JID）がシェル内部で使用される識別子であることを理解すると、外部コマンドの $ kill（/bin/kill） が JID を指定して実行できないことも自然と理解できる（外部コマンドは JID を直接取得することができない。外部コマンドが取得できる JID は、システム全体で共有される、例えば ビルトインシェル変数 などの情報に限られてしまう）。

複数のプロセスで構成されるジョブの場合、最初に実行されるプロセスの PID がそのジョブを代表する PID として扱われ、PGID にはこの PID が使用される。

この最初に実行されるプロセスをジョブの リーダー と表現することがあり、ジョブのリーダーの PID は、そのジョブの実態であるプロセスグループの PGID と一致する。

ジョブの実態はプロセスグループ

フォアグラウンドジョブ

フォアグラウンドで実行中のジョブがある場合、そのジョブがシェルの 標準入力（TTY入力）を占有するため、シェルがキーボード入力を受け付けないように見える。

シグナル Ctrl + C で終了させたり、Ctrl + Z でバックグラウンドに送り、一時停止させることができる。

バックグラウンドジョブ

バックグラウンドで実行中のジョブがあっても、シェルはコマンド入力を受け付ける。

バックグラウンド = 停止 ではなく、バックグラウンドで実行中のジョブもあれば、一時停止中のジョブもある。

バックグラウンドジョブもデフォルトでは 標準出力 が TTY に接続されているため、フォアグラウンドジョブの出力内容と混ざることがある。

過去にバックグラウンドで実行されたコマンドのうち、最後に生成されたプロセスのプロセスIDはビルトインシェル変数の $! に格納されている。

最後に実行されたバックグラウンドジョブを確認する

$ echo $!

&

コマンドの末尾に $ をつけることで、ジョブをバックグラウンドで実行させることができる。

バックグラウンドで実行

$ コマンド &

$ jobs

実行中、もしくは一時停止中のジョブID（JID）を表示する。

実行中、一時停止中のジョブを確認

$ jobs

出力形式

[JID]+ 状態(Running/Stopped) [ジョブの内容]  #  実行中のジョブ
[JID]- 状態(Running/Stopped) [ジョブの内容]  # 直前のジョブ
[JID] 状態(Running/Stopped) [ジョブの内容]

-l でプロセスID（PID）も併せて表示する。

プロセスID も表示

$ jobs -l

$ bg

background

一時停止中のジョブを バックグラウンド で再開する。

バックグラウンドで再開

$ bg %ジョブID

ジョブIDを省略した場合、最後に一時停止したジョブが対象になる。

$ fg

foreground

一時停止中のジョブをフォアグラウンドで再開させる。

または、バックグラウンドで実行中のジョブをフォアグラウンドで実行させる。

フォアグランドで実行させる

$ fg %ジョブID

ジョブIDを省略した場合、最後に操作したジョブ（バクグラウンドのものを含む）が対象になる。

$ disown

own=所有する

現在のジョブリスト（$ jobs）から特定のジョブを削除し、特定のジョブをシェルの管理下から切り離す。

管理対象外とすることで HUP シグナルを受信しなくなるため、ユーザがログアウトしてもプロセスが終了しなくなる。

ジョブをジェルの管理下から外す

$ diswon %ジョブID

タスク

カーネル のスケジューラによって管理される、処理のスケジューリングの単位。

（ただしプロセスやスレッドを含む広い概念であり、文脈によって意味が異なる場合がある）

CPUの処理単位としてスケジューリングされ、以下の状態間を遷移する。

• 実行可能状態（READY）
• 実行状態（RUN）
• 待機状態（WAIT）

Linux ではプロセスとほぼ同義で使用される。

スレッド

一つのプロセス内で実行される処理の実行単位。

一つのプロセス内のスレッド同士は、プロセス内でヒープ領域と呼ばれるメモリ空間を共有するが、スタックと呼ばれるメモリ空間については各スレッドが独立して保持する。正確には、スタックはスレッドごとに独立して確保されるものの、他のスレッドのスタックにアクセスすることは技術的には可能AS。

（Javaのスレッドについては こちら）

サービス / デーモン

メモリ上に常駐することで、バックグラウンド上で特定の機能を提供するプロセス。

通常は SysVinit や systemd によって管理され、自動的に起動されるが、$ systemctl や $ service コマンドによって起動、停止、再起動などの制御を行うことも可能。

ジョブやタスクはコマンド実行時に起動し、処理終了と共に終了するため、継続的に動作し続けるサービス、デーモンとは異なる。

サービスとデーモンの違い

Linux では デーモン はバックグラウンドで動作し、制御端末を持たないプロセスを指す。名前の末尾に d の付くものが多い。

サービス は特に init システムによって管理されるプロセスを指す。デーモンはサービスに含まれる概念であるが、単発のジョブ（Type=oneshot）もサービスとして管理されることがある。

特に systemd では ユニット という概念があり、その中の「サービスユニット（*.service）」が狭義の「サービス」にあたる（ただし、ソケットユニット（*.socket）やタイマーユニット（*.timer）もサービスの一部として機能する場合がある）。

主なデーモン

• Webサーバ
  • httpd
  • apache2
  • nginx
• DBサーバ
  • mysqld
  • postgres
  • mongod
• メールサーバ
  • postfix
  • exim
  • sendmail
• SSHサーバ
  • sshd
• ジョブスケジューラ
  • $ crond

デーモンは通常 init（または systemd）を直接、または間接的な親プロセスとするため、ログインユーザとは独立したプロセスツリーを持つ（プロセスツリーは $ pstree で確認できる）。

プロセスには、「親プロセスが終了したら子プロセスも連動して終了する」特徴があるが、システムの起動時に自動起動したデーモンは ユーザが起動するプロセスとは親子関係にない ため、ユーザがログアウトしても道連れで終了することがない。

標準入出力の扱い

デーモンのプロセスは 標準入出力 を /dev/null に接続しているため、制御端末（TTY）を持たない。

ただし、systemd によって管理されるサービスは journald にログを記録するため、標準出力が /dev/null にリダイレクトされない場合もある（systemctl status で確認可能）。

デーモンのように標準入出力に接続されておらず、制御端末を持たないプロセスは、$ ps aux コマンドで確認すると TTY の項目が ? で表示される。

SysVinit

System V(Five) Init

長年 Linux の標準的な init システムとして使用されてきた、システムの起動やプロセス管理の仕組み。

起動の遅さや並列処理ができないなどの課題があり、Red Hat 系（RHEL、CentOS、Fedora）や Debian 系（Debian、Ubuntu）では、既に後継版である systemd に移行されている。

ただし、一部の軽量ディストリビューション（Alpine Linux など）では、現在も SysVinit が採用されている。

以下の特徴を持つ。

• 「ランレベル」でシステムの状態を管理する
• サービスの起動を 直列処理 で1つずつ順番に起動するため時間がかかる
• サービスが異常終了した場合、自動で復旧しない

SysVinit では カーネルが起動 すると、まず /sbin/init が最初に実行される。

init は PID（プロセスID）が 1 の特別なプロセスであり、システム起動後の最初のプロセスとして動作する。

SysVinit の主な役割は、システム起動時に必要なプロセスを適切に立ち上げ、シャットダウン時に適切に停止することだが、「デーモンを起動する」、「親プロセスが終了した孤立プロセスを引き取る」役割なども併せ持つ。

ユーザが手動で起動したプロセスは init ではなく、シェルなどが親プロセスになる。

init が起動すると、SysVinit は次に、設定ファイル /etc/inittab を読み込んで、どの ランレベル で起動するかを決定する。

ランレベル

システムの状態を管理するための概念のこと。

/etc/inittab に記載されたランレベルに応じて /etc/rcX.d/ （X はランレベルの番号）にあるスクリプトがサービスとして起動される。

/etc/rcX.d/ ディレクトリ内の S や K で始まるファイルは、 /etc/init.d/ ディレクトリに配置されたスクリプトへの シンボリックリンク になっている。

S は start を意味し、K は kill を意味する。

ランレベル	意味
0	システムの停止（シャットダウン）
1	シングルユーザモード root ユーザのみがログインできる
2	マルチユーザモード NFSなし(※)
3	マルチユーザモード NFSあり(※)、GUIなし
4	未使用
5	マルチユーザモード + GUI（X Window）
6	システムの再起動

※ NFS（Network File System）
リモートのサーバにあるファイルをローカルのディレクトリのように扱える仕組み。

例えばサーバー上の /home/shared/ をクライアントの /mnt/shared/ に マウント すれば、まるでローカルファイルのようにアクセスできるようになる。ランレベル 2 では NFS クライアントが無効、3 では有効。

$ runlevel

現在のランレベルを表示する

$ runlevel

$ init / $ telinit

ランレベルを変更する

$ init ランレベル
$ telinit ランレベル

$ service

SystemVinit で使用される サービス 管理用コマンド。

サービスを起動する

$ service サービス start

指定したサービスを停止する

$ service サービス stop

サービスを再起動する

$ service サービス restart

サービスを停止させずに、設定のみ再読み込みする

$ service サービス reload

サービスの状態を確認する

$ service サービス status

$ shutdown

シャットダウンする（halt）

$ shutdown -h now

再起動する（reboot）

$ shutdown -r now

21時にシャットダウンする

$ shutdown -h 21:00

予定したシャットダウンをキャンセルする（cancel）

$ shutdown -c

systemd

従来の SysVinit の後継版として開発され、現在 Linux で主流になっている init システム。

以下の特徴を持つ。

• 並列処理により高速に起動できる
• すべての管理対象（サービス、デバイス、マウントポイントなど）を ユニット という概念により統一的に管理する
• SysVinit のランレベルに相当する ターゲット によりシステム状態を管理する
• 異常終了したサービスを自動で再起動できる
• journald というログ管理システムが組み込まれている

ただし、以下の批判をされることがある。

• SysVinit はシンプルなシェルスクリプトで構成されていたのに対して、systemd はバイナリの実行可能ファイルで構成されており、内部動作が複雑すぎる
• UNIX の「小さなツールを組み合わせる」という設計思想に反して、多機能すぎる
• あまりにも全てを管理しすぎるため、 systemd 依存が強くなる

このため、一部のディストリビューション（Alpine Linux, Devuan, Artix Linux など）は systemd を採用せず、SysVinit や runit、OpenRC などを使い続けている。

ユニット

Unit

systemd では、すべてのサービスやシステムリソースを ユニット で管理する。

ユニットが定義されたファイルを ユニットファイル と呼ぶ。ユニットファイルは systemd がサービスやデバイスの管理を行う際に参照される。

拡張子	説明
.service	デーモンやサービスを管理する Webサーバ：httpd.service、apache2.service、nginx.service DBサーバ：mysqld.service、postgresql.service メールサーバ：postfix.service SSHサーバ：sshd.servic ジョブスケジューラ：crond.service
.target	システムの状態（SysVinitのランレベルに相当）を管理する default.target、graphical.target など
.mount	ファイルシステムの マウント 設定を管理する
.device	デバイスを管理する
.timer	ジョブのスケジュールを管理する（cron に相当する）
.socket	ソケットを管理する

ユニットファイルは下記のディレクトリに格納されている。

ディレクトリ	説明
/etc/systemd/system/	ユーザがカスタマイズしたユニットファイルが格納される 優先順位が最も高い
/run/systemd/system/	一時的な Unit ファイルが格納される 再起動によって消える
/usr/lib/systemd/system/	Linux デフォルトのユニットファイルが格納される ユーザが直接編集しない
/lib/systemd/system/	ディストリビューションによって /usr/lib/systemd/system/ の代わりに使用される
~/.config/systemd/user/	ユーザ単位のユニットファイルが格納される

ユニットファイルは [セクション] 単位で記述され、以下のような構成となっている。

ユニットファイル

[Unit]
Description=説明文
After=起動していることを前提とする別のユニット（起動順の依存関係。ただし、試みるだけで強制力を持たない）
Wants=推奨の依存関係（なくても起動可能）
Requires=必須の依存関係（これが無いと起動しないという別のユニット。強制的な依存関係となるため、一方が停止されるともう一方も停止する。起動も同様。）

[Service] （.service の場合）
ExecStart=実行するコマンドの絶対パス
Restart=再起動の設定（always、on-failure）
User=実行ユーザ名
Group=実行グループ名

[Install]
WantedBy=systemctl enable 時にどのターゲットに関連付けるか

ターゲット

SysVinit のランレベルに相当するもの。

SysVinit のランレベル	対応するターゲット
0	poweroff.target
1	rescue.target
2、3、4	multi-user.target
5	graphical.target
6	reboot.target

$ systemctl

System Control

systemd で使用されるユニット管理用コマンド。

指定するユニットが ***.service の場合、.service を省略できる。

ユニットを起動する

$ systemctl start ユニット

ユニットを停止する

$ systemctl stop ユニット

システムをシャットダウンする

$ systemctl poweroff

ユニットを再起動する

$ systemctl restart ユニット

システムを再起動する

$ systemctl reboot

ユニット（サービス）を停止させずに、設定のみ再読み込みする

$ systemctl reload ユニット # サービスごとに設定ファイルは異なる

ユニット（サービス）を停止させずに、ユニットファイルの変更を反映させる

$ systemctl daemon-reload

$ systemctl reload サービス は特定のサービスの設定を再読み込みするためのコマンド。

$ systemctl daemon-reload は systemd に ユニットファイル の変更を反映させるためのコマンド。

システム起動時にユニットを自動起動する

$ systemctl enable ユニット

システム起動時にユニットを自動起動させない

$ systemctl disable ユニット

ユニットの状態を確認する

$ systemctl status ユニット

ユニットの依存関係を表示する

$ systemctl list-dependencies

ユニットをマスクすることで起動禁止状態にする

$ systemctl mask ユニット

ユニットをマスクすると、ユニットに対する シンボリックリンク が /dev/null に作成される。

マスクを解除する

$ systemctl unmask ユニット

デフォルトのターゲット（起動時に適用される systemd のターゲット）を確認する

$ systemctl get-default

システムのデフォルトのターゲットを変更する

$ systemctl set-default ターゲット

システム起動の流れ

1. 電源ON
   • ハードウェアが起動
2. ファームウェア（BIOS / UEFI）が実行される
   • ハードウェアを初期化し、ブートローダを読み込む
3. ブートローダ（GRUB など）が実行される
   • カーネル をメモリにロード
4. カーネルが起動する
   • ハードウェアや ファイルシステム を認識し、init（または systemd）を起動
5. init（または systemd）によるプロセス管理が開始される
   • ランレベル（SysVinit）またはターゲット（systemd）に応じたサービスが起動

システム起動時にカーネルが画面に出力する情報は、/var/log/dmesg に格納され、$ dmesg にて確認することができる（Ubuntu では /var/log/dmesg は作成されない）。

$ dmesg

/var/log/dmesg に保存された、起動時のカーネルのログを確認する。

起動時のカーネルのログを確認する

$ dmesg

/var/log/dmesg の情報は $ dmesg --clear にて明示的に削除することができる（Ubuntu では /var/log/dmesg は作成されない）。

ファームウェア

Firmware

BIOS （Basic Inpput / Output System）や UEFI （Unified Extensible Fireware Interface）に代表される、コンピュータの基本的な動作制御のためのソフトウェア。

ブートローダ を起動する役割を持つ。

BIOS はマザーボード上の ROM に、UEFI はマザーボード上の フラッシュメモリ（NVRAM）に格納されている。

実体はソフトウェアでありながらハードウェアとソフトウェアの中間的な存在として位置づけられる（firm = 固い、堅牢）。

従来の BIOS は書き換えが難しかったが、最近の UEFI ではアップデートが容易になっている。

UEFI には、デジタル署名済みの信頼できるソフトウェアだけを起動するセキュリティ機能（セキュアブート）もある。

ブートローダ

Boot Loader

GRUB 、Windows Boot Manager に代表される、カーネルをメモリにロードして起動するプログラム。

複数のOSがインストールされているPCなどで、どのOSを起動するかを選択できる機能を デュアルブート や、マルチブート という。

/boot/grub/menu.lst や /boot/grub/grub.conf が設定ファイルとして使用される。

$ grub-install

GRUBをシステムにインストールする

$ sudo grub-install インストール先ディスクのデバイスファイル

例

$ sudo grub-install /dev/sda

スーパーサーバ

複数のデーモンを管理する役割を持つ特別なデーモン。

デーモンは通常、常時メモリ上にいる ため、その分リソースを消費する。スーパーサーバは必要に応じて適切なデーモンを起動することでリソースを節約することができる。一方で、要求を受けてからデーモンが起動するため、応答が遅くなるデメリットがある。

代表的なスーパーサーバには inetd（internet service daemon） や xinetd（extended inetd） がある。

スーパーサーバを経由せず、init や systemd によって起動されるデーモンを スタンドアロンデーモン と言う。

xinetd

/etc/xinetd でシステム全体の設定を行い、 /etc/xinetd.d/ 配下の設定ファイルでサービス固有の設定を行う。

ジョブスケジューラ

cron

デーモン（crond）として常に稼働しているジョブスケジューラ。

1 分おきに crontab （cron table）ファイルの中身を確認している。

cron を利用することで、指定した時間や間隔でコマンドやスクリプトの実行されるようスケジューリングすることができる。

crontab ファイル

cron ジョブが記載される crontab ファイルには、以下の2種類がある。

• ユーザごと の crontab
  • /var/spool/cron/ユーザ名
  • /var/spool/cron/crontabs/ユーザ名
  • エディタで 直接編集しない（$ crontab -e を使用する）
• システム全体 の crontab
  • /etc/crontab
  • /etc/cron.d/（ディレクトリ）
  • エディタで 直接編集する

crontab ファイルの書式は以下のように 小さい単位から大きい単位 の順に記述するようになっている。

ユーザごとの crontab

分 時 日 月 曜日 コマンド

システム全体の crontab

分 時 日 月 曜日 ユーザ名 コマンド

設定項目	指定可能な範囲
分	0 ~ 59
時	0 ~ 23
日	1 ~ 31
月	1 ~ 12
曜日	0 ~ 7 （0、7：日曜日）

特殊文字	意味
*	全ての値 * * * * *：毎分実行
,	複数指定 0,30 * * * *：毎時 0 分と 30 分
-	範囲指定 10-15 * * * *：毎時 10 分 ～ 15 分の間（10, 11, 12, 13, 14, 15分） 0 12 1-5 * *：毎月 1 日 ~ 5 日
/	間隔指定 */5 * * * *：5 分ごと

例（毎日午前3時にスクリプトを実行）

0 3 * * * myscript.sh

例（毎分スクリプトを実行）

* * * * * myscript.sh

関連ディレクトリ

cron に関連するディレクトリには以下のものがある。

ディレクトリ	説明
/var/spool/cron/ユーザ名 /var/spool/cron/crontabs/ユーザ名	ユーザごとの crontab が保存される 直接編集せず $ crontab コマンドで編集する
/etc/crontab	システム全体の crontab ファイル（直接編集可能）
/etc/cron.d/	システム全体の追加の crontab ファイルを配置するディレクトリ
/etc/cron.hourly/	1 時間ごとに実行するスクリプトを配置
/etc/cron.daily/	1 日ごとに実行するスクリプトを配置
/etc/cron.weekly/	1 週間ごとに実行するスクリプトを配置
/etc/cron.monthly/	1 ヶ月ごとに実行するスクリプトを配置

/etc/cron.allow / /etc/cron.deny

ユーザが cron ジョブを実行できるかどうかを制御する設定ファイル。

• /etc/cron.allow
  • cron ジョブを実行できるユーザを指定する
• /etc/cron.deny
  • /etc/cron.allow がない場合にのみ使用される
  • cron ジョブの実行を 禁止するユーザを指定する

$ crontab

cron ジョブ（スケジュールされたタスク）を管理するためのコマンド。

特に /var/spool/cron/ ディレクトリ配下の「ユーザごとの crontab ファイル」を編集するために利用される。

$ cron -e コマンド実行すると、crontab ファイルが規定のエディタによって開かれるため、内容を編集することでジョブを設定することができる。

エディタを利用して crontab ファイルを編集する（edit）

$ crontab -e

各ユーザが $ crontab -e で編集する内容は、内部的には /var/spool/cron/crontabs/ユーザ名 に保存される（システムによっては /var/spool/cron/ユーザ名 になることもある）。

ファイルの名前にユーザ名が使用されることからもわかるように、crontab ファイルへの編集は各ユーザごとに独立しており、他のユーザのジョブには影響することがない。

現在の crontab を表示する（list）

$ crontab -l

crontab ファイルを削除する

$ crontb -r

anacron

cron 同様に設定ファイルでスケジュールされたタスクを実行するジョブスケジューラ。cron デーモンによって起動される。

cron は、予定された時刻にシステムが起動していない場合、ジョブの実行をスキップするのに対して、anacron は次回起動時に実行できなかったジョブをまとめて実行する。

/etc/anacrontab で設定を行う。

$ at

指定したコマンドを 1 回限りで実行する。

$ crontab が定期的なジョブ実行を行うの対して、$ at は 1 回だけ指定した時間に実行したい場合に利用される。

対話形式 でジョブを登録する。

指定した日時にコマンドを実行する

$ at 時間 日付

対話モードになったら、実行させたいコマンドを入力する。Ctrl + D キーで入力を終了する。

スケジュールされたジョブを確認する

$ at -l

スケジュールされたジョブを削除する（delete / remove）

$ at -d ジョブID
$ at -r ジョブID

$ atq

スケジュールされたジョブを確認する

$ atq

$ atrm

スケジュールされたジョブを削除する

$ atrm ジョブID

/etc/at.allow / /etc/at.deny

ユーザが at ジョブを実行できるかどうかを制御する設定ファイル。

• /etc/at.allow
  • at ジョブを実行できるユーザを指定する
• /etc/at.deny
  • /etc/at.allow がない場合にのみ、実行される
  • at ジョブの実行を 禁止するユーザを指定する
• どちらもない場合には root ユーザのみが実行できる

タイマーユニット

systemd のタイマーユニット（*.timer）は、cron と同様に定期的なタスクを実行するための機能。

cron よりも柔軟で管理しやすいメリットがあるが、使い方が難しい。ジョブを実行する cron とは異なり、ターマーユニットは systemd のサービス (*.service) をスケジュール実行する。

.timer ユニットと .service ユニット から構成される。

• .timer ユニット
  • タイマーの設定
  • いつ、どのように実行するかを定義する
• .service ユニット
  • 実行する処理
  • 実際に実行するコマンドやスクリプトを定義する

cron では 1 つのファイル（crontab）でスケジュールとコマンドを設定するが、systemd では スケジュール（.timer）とコマンド（.service）を分けることで管理しやすくなっている。