Linux の 101 試験対策: ランレベル、シャットダウン、およびリブート

システムを立ち上げる

Linux システムをシャットダウンまたはリブートする方法、ユーザーにシステムが停止することを警告する方法、そしてシステムの使い方にさまざまなレベルで制限を設けるためのランレベルを切り替える方法を学んでください。この記事の内容は、Linux のシステム管理者として認定するための LPI 101 試験に備えるためにも、シャットダウン、リブート、およびランレベルの変更について学ぶ上でも役立ちます。

2012年 9月 18日 ― この記事は、LPI による「Exam 101: Objective Changes as of July 2, 2012 (101 試験: 2012年 7月 2日時点での目標の変更)」に対応した内容を含めるように更新されました。

主な更新個所は「init を越えて」、「upstart」、「systemd」、「参考文献」のセクションです。

Ian Shields, Senior Programmer, IBM

Ian ShieldsIan Shields は、developerWorks Linux ゾーンのさまざまな Linux プロジェクトに関わっています。彼はノースキャロライナ州 Research Triangle Park にある IBM のシニア・プログラマーです。1973年にオーストラリアのキャンベラでシステム・エンジニアとして IBM に入社して以来、カナダのモントリオールやノースキャロライナ州 Research Triangle Park で、コミュニケーション・システムやパーベイシブ・コンピューティングに携わってきました。彼はいくつかの特許を保持しています。Australian National University にて純粋数学および哲学で学位を取得し、また North Carolina State University にてコンピューター・サイエンスで修士号と博士号を取得しています。


developerWorks 貢献著者レベル

2012年 10月 18日 (初版 2011年 1月 05日)

この連載について

この連載は Linux システム管理タスクの学習に役立つだけでなく、LPIC-1 (Linux Professional Institute Certification レベル 1) 試験に備えるための教材にもなります。

連載の各記事についての説明とリンクについては、developerWorks の LPIC-1 ロードマップを参照してください。現在進行中のこのロードマップは、LPIC-1 試験の最新の目標 (2009年 4月時点の目標に 2012年 7月のマイナーな更新を加えた目標) を反映しています。完成した記事はその都度ロードマップに追加されていきますが、当面は developerWorks の LPI 認定試験対策チュートリアルで同様の教材の以前のバージョンを調べてください。これらのバージョンは、2009年 4月より前の LPIC-1 目標に対応しています。

概要

この記事では、Linux システムをシャットダウンまたはリブートする方法、ユーザーにシステムが停止することを警告する方法、そしてシングル・ユーザー・モードに切り替えたり、さまざまなレベルの制限があるランレベルに切り替えたりする方法を学びます。記事で説明する内容は以下のとおりです。

  • デフォルト・ランレベルを設定する方法
  • ランレベルを切り替える方法
  • シングル・ユーザー・モードに切り替える方法
  • コマンドラインからシステムをシャットダウンまたはリブートする方法
  • 別のランレベルへの切り替えを含め、重要なシステム・イベントをユーザーに警告する方法
  • プロセスを正常に終了する方法

特に断りのない限り、記事に記載する例では、カーネル 2.6.26 を搭載した Fedora 8 システムを使用しています。ただし、upstart の例で使用しているのは、カーネル 2.6.34 を搭載した Fedora 13、またはカーネル 2.6.35 を搭載した Ubuntu 10.10 です。また、systemd の例ではカーネル 3.4.4 を搭載した Fedora 17 を使用しています。他のシステムでは、結果が異なる場合もあります。

この記事は、Linux Professional Institute の Junior Level Administration (LPIC-1) 101 試験の主題 101 の目標 101.3 の試験対策となります。この目標の重要度は 3 です。

注: この記事には、LPI による「Exam 101: Objective Changes as of July 2, 2012 (101 試験: 2012年 7月 2日時点での目標の変更)」に対応した内容が含まれています。

前提条件

この連載の記事を最大限に活用するには、Linux の基礎知識と、記事に記載されたコマンドを演習できる実際の Linux システムが必要です。プログラムのバージョンによって出力のフォーマットに違いが出てくる場合もあるため、コマンドの実行結果は必ずしもここに記載するリストや図とまったく同じであるとは限りません。特に、最近の upstart および systemd のシステムでは、ユーザーが従来の System V init プロセスで慣れていた内容の多くが変更されています (詳細については「init を越えて」を参照)。この記事は主に従来の System V init プロセスを対象にしていますが、update や systemd ではどのような違いがあるかについての簡単な概要も説明します。


ランレベル

Ian とつながるには

Ian は developerWorks で人気の高いお馴染みの著者の 1 人です。Ian が書いたすべての developerWorks 記事を閲覧してみてください。また、My developerWorks では、Ian のプロフィールを調べることや、彼やその他の著者、そして他の読者とつながることができます。

ランレベルは、Linux システムの現在の状態 (つまりランレベル) で実行可能なタスクを定義します。すべての Linux システムは 3 つの標準ランレベルに加え、通常の動作をするための 1 つ以上のランレベルをサポートします。表 1 に、標準ランレベルを記載します。

表 1. Linux の標準ランレベル
レベル用途
0システムのシャットダウン (または停止)
1シングル・ユーザー・モード (通常、別名として s または S が使われます)
6システムのリブート

標準ランレベルの他に使用されるランレベルは、ディストリビューションによって異なります。表 2 に一例として、よく使用されるランレベル一式を記載します。

表 2. その他の一般的な Linux ランレベル
レベル用途
2ネットワークを使用しないマルチユーザー・モード
3ネットワークを使用したマルチユーザー・モード
5ネットワークと X Window System を使用したマルチユーザー・モード

Slackware ディストリビューションは、X Window System を実行するシステム全体に対し、ランレベル 5 ではなく、ランレベル 4 を適用します。Debian とその派生ディストリビューション (Ubuntu など) は、すべてのマルチユーザー・モードに 1 つのランレベル (通常は、ランレベル 2) を共通して使用します。ランレベルについては、各ディストリビューションのマニュアルを調べてください。


デフォルト・ランレベル

デフォルト・ランレベルは、Linux システムの起動時に、/etc/inittab に含まれる id: というエントリーから判断されます。リスト 1 に、X Window System 用にランレベル 5 を使用する Fedora 8 や openSUSE 11.2 などのシステムに典型的なエントリーを示します。

リスト 1. /etc/inittab 内のデフォルト・ランレベル
[root@pinguino ~]# grep "^id:" /etc/inittab
id:5:initdefault:

システムを別のランレベル、例えばランレベル 3 で起動させたい場合には、このエントリーの値を編集することになります。


ランレベルの変更

ランレベルを変更するには、いくつかの方法があります。ランレベルを恒久的に変更する場合は、上記で説明した /etc/inittab を編集してデフォルト・レベルを変更します。

あるブートに限り、システムを別のランレベルで立ち上げることもできます。例えば、新しいカーネルをインストールしたとして、システムがその新しいカーネルでブートした後、X Window System を起動する前にいくつかのカーネル・モジュールをビルドする必要がある場合を考えてみてください。この作業を可能にするには、システムをランレベル 3 で立ち上げるようにするとよいでしょう。このように、ブート時に特定のランレベルでシステムを起動するには、kernel 行を編集するか (GRUB の場合)、選択したシステム名の後にパラメーターを追加します (LILO の場合)。目的のランレベル (この例では 3) は、1 桁の数字で指定してください。これから GRUB を例に、このプロセスを説明します。/boot/grub/menu.lst ファイルには、リスト 2 に記載するスタンザが含まれているという前提です。

リスト 2. Fedora 8 をブートするための典型的な GRUB スタンザ
title Fedora (2.6.26.8-57.fc8)
        root (hd0,5)
        kernel /boot/vmlinuz-2.6.26.8-57.fc8 ro root=LABEL=FEDORA8 rhgb quiet
        initrd /boot/initrd-2.6.26.8-57.fc8.img

このシステムをランレベル 3 で起動するには、ブート・エントリーが表示されるのを待ってから、上記のエントリーを選択し、「e」を入力してエントリーを編集できるようにします。GRUB のオプションによっては、ブート・エントリーを表示するためのキーを押して、編集をロック解除するために「p」と入力し、続いてパスワードを入力しなければならない場合もあります。図 1 は、Fedora 8 システムでの GRUB 画面の一例です。

図 1. GRUB でブート選択項目を選択する
GRUB でブート選択項目を選択する

この例の場合には、root、kernel、および initrd の行が表示されます。「kernel」で始まる行にカーソルを移動し、この行を編集するために「e」を押します。Fedora 8 システムでの GRUB 画面は、図 2 のように表示されているはずです。

図 2. 編集対象とする kernel エントリーを選択する
編集対象とする kernel エントリーを選択する

続いて行の末尾にカーソルを移動し、スペースに続けて数字「3」を入力します。必要に応じて、「quiet」の部分を削除したり、他のパラメーターを変更したりしても構いません。この操作によって、Fedora 8 システムでの GRUB 画面は、図 3 のようになります。

図 3. 開始ランレベルを 3 に設定する
開始ランレベルを 3 に設定する

最後に Enter キーを押して変更を保存し、「b」を入力してシステムをブートします。

注: LILO または GRUB2 を使用してランレベルを変更する手順は、GRUB を使用して行う場合の手順と同じではありませんが、カーネルを起動する方法を編集するという基本原則は変わりません。他のシステムや他のディストリビューションでの GRUB 画面は、上記に示した画面とはかなり異なるかもしれませんが、通常は、操作を支援するプロンプトが表示されます。

ランレベル 3 で行わなければならないセットアップ作業を完了した後、おそらくランレベル 5 に切り替えることになると思いますが、この場合、システムをリブートする必要はありません。telinit コマンドを使用すれば、別のランレベルに切り替えることができます。前のランレベルと現在のランレベルの両方を表示するには、runlevel コマンドを使用します。最初の出力文字が「N」となっている場合、これは、システムがブートされてからランレベルは一度も変更されていないことを意味します。リスト 3 に、ランレベルを確認する方法と変更する方法を示します。

リスト 3. ランレベルの確認および変更
[root@pinguino ~]# runlevel
N 3
[root@pinguino ~]# telinit 5

telinit  5」と入力すると、いくつかのメッセージが立て続けに表示されてから、構成済みのグラフィカル・ログイン画面に表示が切り替わります。ターミナル・ウィンドウを開いて、リスト 4 に示されているように、ランレベルが変更されていることを確認してください。

リスト4. 変更後のランレベルの確認
[root@pinguino ~]# runlevel
3 5

ls コマンドを使って telinit コマンドの詳細リストを表示してみると、このコマンドは実際には init コマンドへのシンボリック・リンクであることがわかります。リスト 5 に、この詳細リストを記載します。

[root@pinguino ~]# ls -l $(which telinit)
lrwxrwxrwx 1 root root 4 2008-04-01 07:50 /sbin/telinit -> init

init 実行プログラムは、このプログラムが init として呼び出されたのか、または telinit として呼び出されたのかを認識し、それに応じて振る舞います。init はブート時に PID 1 として実行されるため、ユーザーがそれ以降に telinit ではなく init を使用して呼び出した場合にも、それを認識するだけの賢さを持ち合わせています。init を使用して呼び出した場合には、このプログラムはユーザーが telinit を呼び出したかのように振る舞います。したがって、例えば telinit 5 の代わりに init 5 を使用してランレベル 5 に切り替えることもできます。


シングル・ユーザー・モード

DOS や Window などのパーソナル・コンピューターのオペレーティング・システムとは対照的に、Linux は本質的にマルチユーザー・システムです。けれども、主要なファイルシステムやデータベースを回復しなければならない場合や、新しいハードウェアをインストールしてテストするときなど、マルチユーザー・システムであることが問題になる場合もあります。この問題に対する答えとなるのが、ランレベル 1 のシングル・ユーザー・モードです。実際の実装はディレクトリビューションによって異なりますが、通常はシェル内で最小限のシステムを起動します。したがって、ネットワーク機能もなく、実行中のデーモンもない (あるいは、ほんのいくつかのデーモンだけが実行されている) のが通常です。一部のシステムではログインによる認証が必要となりますが、それ以外のシステムでは root として直接シェル・プロンプトを表示することができます。シングル・ユーザー・モードはいざというときの救いの手となる一方、システムを破壊する可能性もあるので、root 権限で実行しているときには常に注意が必要です。シングル・ユーザー・モードでの作業が終わったら、直ちに通常のマルチユーザー・モードでリブートしてください。

通常のマルチユーザー・ランレベルへの切り替えと同様、「telinit 1」を使用してシングル・ユーザー・モードに切り替えることもできます。表 1 に記載されているように、ランレベル 1 の別名は「s」と「S」なので、代わりに「telinit s」を使用するのでも構いません。


正常なシャットダウン

マルチユーザーのアクティビティーを停止してシングル・ユーザー・モードに切り替えるには、telinit または init を使用することができますが、どちらかというと不意に切り替えられることが多いため、ユーザーが作業結果を失ったり、プロセスが異常終了したりする可能性があります。それよりも望ましい方法でシステムをシャットダウンまたはリブートするには、shutdown コマンドを使用します。このコマンドはまず、ログインしているすべてのユーザーに警告メッセージを送信すると同時に、以降のログインをブロックします。その上で、ランレベルを切り替えるように init にシグナルを送ります。すると、init プロセスが実行中のすべてのプロセスに SIGTERM シグナルを送出し、データを保存する機会、あるいはプロセスを正常に終了する機会を与えます。5 秒後、または別途時間が指定されている場合は、その時間経過後、まだ実行中のプロセスがあれば、init は SIGKILL シグナルを送出してその各プロセスを強制終了するという仕組みです。

デフォルトでは、shutdown はランレベル 1 (シングル・ユーザー・モード) に切り替えますが、-h オプションを指定してシステムを停止することも、-r オプションを指定してリブートすることもできます。その際、標準メッセージと併せて、指定した任意のメッセージが発行されます。シャットダウンする時刻は、hh:mm 形式の時刻として指定するか、または相対時間として n を指定します (n はシャットダウンするまでの分数)。即時にシャットダウンする場合には、now を使用します。now は、+0 に相当します。

遅延シャットダウンを発行した後、遅延時間がまだ満了していなければ、シャットダウンをキャンセルすることができます。それには、コマンドがフォアグラウンドで実行されている場合には Ctrl-c を押し、保留中のシャットダウンをキャンセルする場合には、-c オプションを指定した shutdown を実行します。リスト 6 に記載するいくつかの例で、shutdown コマンドを使用する方法、そしてこのコマンドをキャンセルする方法を説明します。

リスト 6. シャットダウンの例
[root@pinguino ~]# shutdown 5 File system recovery needed

Broadcast message from root (pts/1) (Tue Jan  4 08:05:24 2011):

File system recovery needed
The system is going DOWN to maintenance mode in 5 minutes!
^C
Shutdown cancelled.
[root@pinguino ~]# shutdown -r 10 Reloading updated kernel&
[1] 18784
[root@pinguino ~]#
Broadcast message from root (pts/1) (Tue Jan  4 08:05:53 2011):

Reloading updated kernel
The system is going DOWN for reboot in 10 minutes!

[root@pinguino ~]# fg
shutdown -r 10 Reloading updated kernel
^C
Shutdown cancelled.
[root@pinguino ~]# shutdown -h 23:59&
[1] 18788
[root@pinguino ~]# shutdown -c

Shutdown cancelled.
[1]+  Done                    shutdown -h 23:59

お気付きかもしれませんが、上記の最後の例では、警告メッセージが送信されていません。シャットダウンまでの時間が 15 分を超えている場合、リスト 7 に示されているように、シャットダウンの 15 分前になるまでメッセージは送信されないからです。リスト 7 では、SIGTERM シグナルを送ってから SIGKILL シグナルを送るまでのデフォルト遅延を 5 秒から 60 秒に延ばすために、-t オプションも使用しています。

リスト 7. 別のシャットダウンの例
[root@pinguino ~]# date;shutdown -t60 17 Time to do backups&
Tue Jan  4 08:12:55 EST 2011
[1] 18825
[root@pinguino ~]# date
Tue Jan  4 08:14:13 EST 2011
[root@pinguino ~]#
Broadcast message from root (pts/1) (Tue Jan  4 08:14:55 2011):

Time to do backups
The system is going DOWN to maintenance mode in 15 minutes!

シャットダウンをキャンセルするとしたら、wall コマンドを使用して、すべてのユーザーに警告を送信し、システムは停止されないことを通知してください。

前述のとおり、telinit (または init) を使用してシステムをシャットダウン、またはリブートすることも可能です。しかし、他の目的で telinit を使用する場合と同じく、ユーザーには警告メッセージが送信されません。しかも、SIGTERM シグナルを送出してから SIGKILL シグナルを送出するまでの遅延がまだあるとしても、コマンドは即時に実行されます。telinitinit、および shutdown で使用できるその他のオプションについては、該当する man ページを参照してください。


停止、リブート、電源オフ

シャットダウンとリブートに関連するコマンドには、他にもいくつか知っておかなければならないものがあります。

  • halt コマンドは、システムを停止します。
  • poweroff コマンドは、halt コマンドへのシンボリック・リンクで、システムを停止してから、電源オフを試みます。
  • rebootcommand コマンドも同じく halt コマンドへのシンボリック・リンクで、システムを停止した後、システムをリブートします。

システムのランレベルが 0 または 6 ではないときに、上記のいずれかのコマンドが呼び出されると、対応する shutdown コマンドが代わりに実行されます。

この 3 つのコマンドで使用できるオプションと、実行される内容についての詳細は、man ページを参照してください。


/etc/inittab

これまでの説明で、なぜ一部のシステムでは Ctrl-Alt-Delete を押すとリブートするのか、あるいはこのランレベルというものがどのように構成されているのかを不思議に思っている読者もいるでしょう。/etc/inittab の id フィールドを思い出してください。/etc/inittab にはもちろんこのフィールド以外にもフィールドがあり、各ディレクトリー内に格納された rc1.d や rc5.d などの一連の init スクリプトが指定されています。ここで、スクリプト名の数字はそのディレクトリー内のスクリプトが適用するランレベルを示しています。リスト 8 に、この記事で使用している Fedora 8 システムの inittab ファイルの内容全体を記載します。

リスト 8. Fedora 8 の inittab ファイルの全容
#
# inittab       This file describes how the INIT process should set up
#               the system in a certain run-level.
#
# Author:       Miquel van Smoorenburg, <miquels@drinkel.nl.mugnet.org>
#               Modified for RHS Linux by Marc Ewing and Donnie Barnes
#

# Default runlevel. The runlevels used by RHS are:
#   0 - halt (Do NOT set initdefault to this)
#   1 - Single user mode
#   2 - Multiuser, without NFS (The same as 3, if you do not have networking)
#   3 - Full multiuser mode
#   4 - unused
#   5 - X11
#   6 - reboot (Do NOT set initdefault to this)
#
id:5:initdefault:

# System initialization.
si::sysinit:/etc/rc.d/rc.sysinit

l0:0:wait:/etc/rc.d/rc 0
l1:1:wait:/etc/rc.d/rc 1
l2:2:wait:/etc/rc.d/rc 2
l3:3:wait:/etc/rc.d/rc 3
l4:4:wait:/etc/rc.d/rc 4
l5:5:wait:/etc/rc.d/rc 5
l6:6:wait:/etc/rc.d/rc 6

# Trap CTRL-ALT-DELETE
ca::ctrlaltdel:/sbin/shutdown -t3 -r now

# When our UPS tells us power has failed, assume we have a few minutes
# of power left.  Schedule a shutdown for 2 minutes from now.
# This does, of course, assume you have powerd installed and your
# UPS connected and working correctly.
pf::powerfail:/sbin/shutdown -f -h +2 "Power Failure; System Shutting Down"

# If power was restored before the shutdown kicked in, cancel it.
pr:12345:powerokwait:/sbin/shutdown -c "Power Restored; Shutdown Cancelled"


# Run gettys in standard runlevels
1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
4:2345:respawn:/sbin/mingetty tty4
5:2345:respawn:/sbin/mingetty tty5
6:2345:respawn:/sbin/mingetty tty6

# Run xdm in runlevel 5
x:5:respawn:/etc/X11/prefdm -nodaemon

いつもの如く、# で始まる行はコメントです。その他の行には、複数のフィールドが以下の形式で記載されています。
id:runlevels:action:process

id
一意に決まる 1 文字から 4 文字の ID です。古いバージョンでは ID が 2 文字に制限されていたので、2 文字しか使用されていない ID を目にすることもよくあるはずです。
runlevels
この id のアクションを実行するランレベルを記載します。ランレベルが 1 つも記載されていない場合、そのアクションをすべてのランレベルで実行します。
action
実行可能なアクションのうち、どのアクションを実行するかを記述します。
process
この行に記載されたアクションが行われるときに実行しなければならないプロセスがある場合、そのプロセスを示します。

表 3 に、etc/inittab に指定することができる一般的なアクションのいくつかを記載します。この表に記載されていないアクションについては、inittab の man ページを参照してください。

表 3. inittab に記載される一般的なアクション
アクション用途
respawnプロセスが終了した場合は常にそのプロセスを再起動します。通常、このアクションは、ログインをモニターする getty プロセスに対して指定されます。
wait指定されたランレベルが適用されたときにプロセスを一度起動します。init は、そのプロセスが終了してから処理を続行します。
once指定されたランレベルが適用されたときにプロセスを一度起動します。
initdefaultシステム・ブート後に適用するランレベルを指定します。
ctrlaltdelinit が SIGINT シグナルを受け取ったときに (例えば、システム・コンソールでユーザーが CTRL-ALT-DEL を押したときなど)、関連付けられたプロセスを実行します。

リスト 9 に、リスト 8 から抜粋した Ctrl-Alt-Delete に対応するエントリーを記載します。これを見れば、Ctrl-Alt-Delete を押すとシステムがリブートする理由がわかるはずです。

リスト 9. Ctrl-Alt-Delete の捕捉
# Trap CTRL-ALT-DELETE
ca::ctrlaltdel:/sbin/shutdown -t3 -r now

初期化スクリプト

リスト 8 には以下のような行が複数含まれていたことにお気付きでしょうか。

l5:5:wait:/etc/rc.d/rc 5

上記の例では、ランレベル 5 が適用されると常に、init がパラメーター 5 を設定した /etc/rc.d/rc スクリプト (コマンド) を実行することになります。init はこのコマンドが完了するまで、別の操作を行いません。

システムの起動時、ランレベルの変更時、またはシャットダウン時に init が使用するスクリプトは、一般に /etc/init.d または /etc/rc.d ディレクトリーに格納されます。rcn.d ディレクトリー (それぞれのランレベル (n) に対して 1 つの rcn.d ディレクトリー) 内にある一連のシンボリック・リンクが、そのランレベルが適用されたときにスクリプトを実行するかどうか、あるはそのランレベルから別のランレベルに変更されたときにスクリプトを停止するかどうかを制御します。これらのシンボリック・リンクの名前は、K または S のいずれかで始まり、その後に 2 桁の数字とサービスの名前が続きます (リスト 10 を参照)。

リスト 10. init スクリプト
[root@pinguino ~]# find /etc -path "*rc[0-9]*.d/???au*"
/etc/rc.d/rc2.d/S27auditd
/etc/rc.d/rc2.d/K72autofs
/etc/rc.d/rc4.d/S27auditd
/etc/rc.d/rc4.d/S28autofs
/etc/rc.d/rc5.d/S27auditd
/etc/rc.d/rc5.d/S28autofs
/etc/rc.d/rc0.d/K72autofs
/etc/rc.d/rc0.d/K73auditd
/etc/rc.d/rc6.d/K72autofs
/etc/rc.d/rc6.d/K73auditd
/etc/rc.d/rc1.d/K72autofs
/etc/rc.d/rc1.d/K73auditd
/etc/rc.d/rc3.d/S27auditd
/etc/rc.d/rc3.d/S28autofs
[root@pinguino ~]# cd /etc/rc.d/rc5.d
[root@pinguino rc5.d]# ls -l ???a*
lrwxrwxrwx 1 root root 16 2008-04-07 11:29 S27auditd -> ../init.d/auditd
lrwxrwxrwx 1 root root 16 2008-04-01 07:51 S28autofs -> ../init.d/autofs
lrwxrwxrwx 1 root root 15 2008-04-01 14:03 S44acpid -> ../init.d/acpid
lrwxrwxrwx 1 root root 13 2008-04-01 07:50 S95atd -> ../init.d/atd
lrwxrwxrwx 1 root root 22 2008-04-01 07:54 S96avahi-daemon -> ../init.d/avahi-daemon
lrwxrwxrwx 1 root root 17 2008-11-17 13:40 S99anacron -> ../init.d/anacron

上記を見ると、audit および autofs サービスの Knn エントリーはすべてのランレベルにあり、ランレベル 3 と 5 には Snn エントリーもあることがわかります。S は、そのランレベルになるとサービスが起動されることを意味し、K エントリーはサービスが停止されることを意味します。リンク名の nn の部分が示すのは、サービスを起動または停止する優先順位です。この例では、auditautofs より前に起動され、停止されるのは autofs の後ということになります。

詳細については、init および inittab の man ページを参照してください。


init を越えて

この記事で目にしてきたように、Linux システムをブートする従来の方法は、UNIX System V の init プロセスがベースとなっています。このプロセスでは、初期 RAM ディスク (initrd) をロードした後、一般に sysvinit パッケージの一部としてインストールされている init というプログラムに制御を渡します。init プログラムはこのシステムにおける最初のプロセスであり、PID (プロセス ID) 1 を持っています。init はシステムを立ち上げるために、事前に定義された順序で一連のスクリプトを実行します。その際、スクリプトの実行に必要なデバイスが使用できなければ、それが使用可能になるまで init プロセスは待機します。この方法は、すべてのデバイスが既知であり、システムの起動時にすべて接続されているシステムでは適切に機能しました。けれども最近のシステムでは、ホットプラグ可能なデバイス、ネットワーク・ファイルシステム、さらには起動時には使用できない可能性があるネットワーク・インターフェースなどが使われるため、新たな問題が提示されるようになってきました。長期間 (あるいは比較的長い期間というだけでも) 使用可能にならない可能性のあるハードウェアを待機するのは、明らかに望ましいことではありません。

この記事の以下のセクションでは、System V の init に代わる 2 つのプロセスとして、upstart と systemd について説明します。


upstart

新しい初期化プロセス upstart は 2006年に Ubuntu 6.10 (「Edgy Eft」) で初めて導入されました。Fedora 9 から Fedora 14、そして Red Hat Enterprise Linux (RHEL) 6 では upstart を使用しており、これらから派生したディストリビューションでも同様です。現在、特に Ubuntu では、init プロセスに代わって upstart が使用されるようになっていますが、init の痕跡はまだ残っています。upstart の力が完全に発揮されるまでには、まだ時間がかかりそうです。

以前のシステムでは init スクリプトが静的に使われていましたが、それとは対照的に、upstart システムはイベントによって駆動されます。イベントをトリガーするのは、ハードウェアの変更、タスクの開始または停止、あるいはシステム上の他のプロセスなどです。これらのイベントを使用して、ジョブとして総称されるタスクまたはサービスがトリガーされます。例えば、USB ドライブを接続すると、udev サービスがブロック・デバイス追加イベントを送信し、それによって、決められたタスクが /etc/fstab をチェックし、該当する記述がある場合にはそのドライブをマウントするといった具合です。また、ネットワークと必須ファイルシステム・リソースの両方が使用可能な場合に限り、Apache Web サーバーを起動することができる、といった別の例もあります。

/sbin/init の代わりとなるのは、upstart 初期化プログラムです。upstart ジョブは、/etc/init ディレクトリーとそのサブディレクトリーに定義されます。現在提供されている upstart システムは、/etc/inittab および System V の init スクリプトを処理します。Fedora の最近のリリースなどでは、システムの /etc/inittab に含まれているのは、おそらく initdefault アクションの id エントリーだけです。最近の Ubuntu システムには、デフォルトでは etc/inittab がありませんが、デフォルト・ランレベルを指定する必要がある場合には、このディレクトリーを作成することも可能です。

upstart には、upstart の init デーモンを操作するための initctl コマンドもあります。このコマンドを使用することで、ジョブの開始または停止、ジョブの一覧表示、ジョブの状態の取得、イベントの発行、init プロセスの再起動などを行うことができます。例として、リスト 11 に initctl を使用して Fedora 13 システム上の upstart ジョブの一覧を取得する方法を示します。

リスト 11. initctl コマンドによる upstart の init デーモンの操作
[ian@echidna ~]$ initctl list
rc stop/waiting
tty (/dev/tty3) start/running, process 1486
tty (/dev/tty2) start/running, process 1484
tty (/dev/tty6) start/running, process 1492

tty (/dev/tty5) start/running, process 1490
tty (/dev/tty4) start/running, process 1488
plymouth-shutdown stop/waiting
control-alt-delete stop/waiting
system-setup-keyboard start/running, process 1000
readahead-collector stop/waiting
vpnc-cleanup stop/waiting
quit-plymouth stop/waiting
rcS stop/waiting
prefdm start/running, process 1479
init-system-dbus stop/waiting
ck-log-system-restart stop/waiting
readahead stop/waiting
ck-log-system-start stop/waiting
start-ttys stop/waiting
readahead-disable-services stop/waiting
ck-log-system-stop stop/waiting
rcS-sulogin stop/waiting
serial stop/waiting

upstart について詳しく学ぶには、「参考文献」を参照してください。


Systemd

さらにもう 1 つの新しい初期化システムとして systemd も登場しています。systemd は 2010年の初頭に Lennart Poettering 氏によって開発されました。彼はブログの投稿で、systemd を開発した論理的な理由とその設計について説明しています (「参考文献」を参照)。systemd は Fedora 15 や、openSUSE 12.1、Mandriva 2011 などで採用されています。

デーモン・プロセスの多くはソケットを使用して通信を行います。systemd ではシステム起動時の処理速度と並列性を高めるために、デーモン・プロセスが使用するソケットを起動時に作成します。しかし、そのソケット上でサービスに対する接続要求を受け取るまでは、関連するタスクを起動しません。このように、サービスを起動するのは最初にサービスが要求された時点であり、必ずしもシステム初期化時に起動するわけではありません。他の機能を必要とするサービスは、その機能が使用可能になるまでブロック状態になります。つまり、あるプロセスを起動している間、そのプロセスを待機しているサービスのみがブロックされた状態になります。

systemd では、このサービスを待機するという考えを拡張し、autofs を使用してマウント・ポイントを定義します。そのため、ファイルシステムのマウント・ポイントは使用可能であっても、実際のマウントは、何らかのプロセスがファイルシステム上のファイルを開こうとするか、あるいはそのファイルを使おうとするまで遅らせられる可能性があります。

サービスを利用するためのインターフェースは、サービスそのものが必要となる時点のかなり前に準備ができている場合があるので、こうした考えを採り入れることによって、必要になるまでサービスの起動を遅らせられることになり、さらにはサービス間の依存関係の確認という必須の作業を減らすことになります。

upstart と同様に、systemd では /etc/inittab によって既存の初期化の処理を行うことができます。また、ファイルシステムのマウントを制御するために /etc/fstab を処理することもできます。systemd ネイティブの初期化はユニットの概念を中心に進められ、ユニットはコントロール・グループ、つまり cgroup にグループ化することができます。

  • サービス・ユニットは、起動、停止、再起動、リロードが可能なデーモンです。
  • ソケット・ユニットは、ファイルシステム内またはインターネット上でソケットをカプセル化します。
  • デバイス・ユニットは、Linux デバイス・ツリー内でデバイスをカプセル化します。
  • マウント・ユニットは、ファイルシステム階層内でマウント・ポイントをカプセル化します。
  • オートマウント・ユニットは、ファイルシステム階層内でオートマウント・ポイントをカプセル化します。
  • ターゲット・ユニットは、他のユニットをグループ化し、他の複数のユニットに対して単一のコントロール・ユニットを提供します。
  • スナップショット・ユニットは他のユニットを参照する一方で、例えばサスペンド中などに、init システムのすべてのサービスおよびユニットの状態を保存およびロールバックするために使用することができます。

ユニットの構成には、構成ファイルが使用され、構成ファイルにはサフィックスとしてユニットのタイプが含まれます。例えば、cups.service、rpcbind.socket、getty.target といった形です。システム構成ファイルの格納場所は、pkg-config コマンドを使用して明らかにすることができます。例えば、リスト 12 に示すように pkg-config コマンドによって Fedora 17 システムでのシステム構成ファイルの場所が /etc/systemd/system であることが示されます。systemd はまた、/usr/local/lib/systemd/system と /usr/lib/systemd/system で構成情報を確認します。

リスト 12. systemd のシステム構成ディレクトリーを調べる
[ian@attic4 ~]$ pkg-config systemd --variable=systemdsystemconfdir
/etc/systemd/system

systemctl コマンドを使用すると、systemd デーモンに問い合わせをしたり、systemd デーモンを制御したりすることができます。例えば、ユニットの起動や停止を行ったり、ユニットのステータスを表示したりすることができます。リスト 13 に、systemctl を使用して system ユニットのステータスを表示する方法を示します。

リスト 13. systemctl コマンドの出力の抜粋
[ian@attic4 ~]$ systemctl --no-pager
UNIT                      LOAD   ACTIVE SUB       JOB DESCRIPTION
proc-sys...misc.automount loaded active running       Arbitrary Executable File
sys-devi...et-eth0.device loaded active plugged       RTL8111/8168B PCI Express
sys-devi...da-sda1.device loaded active plugged       WDC_WD6401AALS-00L3B2
sys-devi...a-sda10.device loaded active plugged       WDC_WD6401AALS-00L3B2
sys-devi...a-sda11.device loaded active plugged       WDC_WD6401AALS-00L3B2
sys-devi...a-sda12.device loaded active plugged       WDC_WD6401AALS-00L3B2
sys-devi...da-sda2.device loaded active plugged       WDC_WD6401AALS-00L3B2
...
systemd-...ssions.service loaded active exited        Permit User Sessions
systemd-...-setup.service loaded active exited        Setup Virtual Console
tcsd.service              loaded failed failed        LSB: Init script for TCSD
udev-settle.service       loaded active exited        udev Wait for Complete Dev
udev-trigger.service      loaded active exited        udev Coldplug all Devices
udev.service              loaded active running       udev Kernel Device Manager
udisks2.service           loaded active running       Storage Daemon
upower.service            loaded active running       Daemon for power managemen
avahi-daemon.socket       loaded active listening     Avahi mDNS/DNS-SD Stack Ac
cups.socket               loaded active running       CUPS Printing Service Sock
...
syslog.target             loaded active active        Syslog
systemd-...ted-ntp.target loaded active active        Network Time Protocol
systemd-...ead-done.timer loaded active elapsed       Stop Read-Ahead Data Colle
systemd-...es-clean.timer loaded active waiting       Daily Cleanup of Temporary

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.
JOB    = Pending job for the unit.

132 units listed. Pass --all to see inactive units, too.

systemd について詳しく学ぶには、「参考文献」を参照してください。

これで、Linux のランレベル、シャットダウン、リブートについての基本的な説明は終了です。

参考文献

学ぶために

製品や技術を入手するために

  • ご自分に最適な方法で IBM 製品を評価してください。評価の方法としては、製品の試用版をダウンロードすることも、オンラインで製品を試してみることも、クラウド環境で製品を使用することもできます。また、SOA Sandbox では、数時間でサービス指向アーキテクチャーの実装方法を効率的に学ぶことができます。

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Linux
ArticleID=620254
ArticleTitle=Linux の 101 試験対策: ランレベル、シャットダウン、およびリブート
publish-date=10182012