Linux の 101 試験対策: ランレベル、ブート・ターゲット、シャットダウン、リブート

システムを立ち上げる

Linux システムをシャットダウンまたはリブートする方法、ユーザーにシステムが停止することを警告する方法、そしてシステムの使い方にさまざまなレベルで制限を設けるためのランレベルを切り替える方法を学んでください。このチュートリアルの内容は、2015年 4月に更新された LPI の試験項目のバージョン 4.0 に対応しており、LPIC-1: Linux Server Professional Certification に備えて勉強するために利用することも、単にシャットダウン、リブート、そしてランレベルの変更について学ぶために利用することもできます。

Ian Shields, Linux Author, Freelance

Ian ShieldsIan Shields は、Linux のフリー・ライターです。ノースカロライナ州 Research Triangle Park にある IBM を退職した彼が、オーストラリアのキャンベラにある IBM にシステム・エンジニアとして入社したのが 1973年であり、それ以降、カナダのモントリオールやノースカロナイナ州 Research Triangle Park でシステム・エンジニアリングとソフトウェア開発の両方に携わってきました。1990年代後半からは、Linux を使用して Linux 上で開発を行うとともに、Linux に関する執筆も行ってきました。彼は、オーストラリア国立大学で純粋数学および哲学の学士号を取得し、ノースカロライナ州立大学でコンピューター・サイエンスの修士号と博士号を取得しています。普段はオリエンテーリングを楽しんでおり、旅行に行くのも好きです。


developerWorks 貢献著者レベル

2016年 7月 07日 (初版 2011年 1月 05日)

より詳しく学び、さらなる開発を行い、より多くの人とつながる

新たに登場した developerWorks Premium メンバーシップ・プログラムでは、メンバーになると、強力な開発ツールのほか、Safari Books Online を通じて提供される最もホットな 500 タイトルの技術書 (Java 開発者向けのものが大量にあります) を含む各種のリソースをすべて自由に利用できるようになります。さらに、主要な開発者向けイベントの登録料の大幅な割引や、最新の O'Reilly カンファレンスの全容を閲覧できる再生動画など、その他にもさまざまな特典が提供されます。今すぐサインアップしてください

概要

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

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

特に断りのない限り、チュートリアルに記載する例では、カーネル 2.6.37 を搭載した Slackware 13.37 システムを使用しています。ただし、upstart の例で使用しているのは、カーネル 3.16.0 を搭載した Ubuntu 14.04 LTS です。また、systemd の例ではカーネル 4.0.4 を搭載した Fedora 22 を使用しています。他のシステムでは、結果が異なる場合もあります。


Linux を実行する

ほとんどの場合にマルチユーザー・システムとして実行される Linux システムは、いくつかの異なるユーザー ID の下で数多くの異なるプロセスが実行されるサーバーという形態をとるのが一般的です。場合によっては、グラフィカル・ユーザー・インターフェースを備えていて、主にシングル・ユーザーにサービスを提供することもありますが、それ以外の場合は、多くのユーザーを対象として動作するヘッドレス・サーバーです。何らかのシステム・メンテナンスを行う必要がある場合には、これらすべてのユーザーが作業を行おうとして欲しくはないため、システムを多数のユーザーで実行するのではなく、シングル・ユーザーで実行できるようにする必要があります。さらに、このユーザー・モードを手際よく切り替えるために、ログイン済みユーザーに対して適切な警告を発する必要があります。そしてできるだけ迅速に、通常の動作に戻す必要があります。このチュートリアルでは、その方法を紹介します。

この連載について

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

連載の各チュートリアルに関する説明とリンクについては、developerWorks の「Linux の 101 試験対策: LPIC-1 のロードマップ」を参照してください。現在進行中のこのロードマップは、2015年 4月 15日に更新された LPIC-1 試験の項目のバージョン 4.0 を反映しています。完成したチュートリアルは、その都度ロードマップに追加されていきます。

このチュートリアルは、Linux Server Professional (LPIC-1) 101 試験の主題 101 の 101.3 の試験対策に役立ちます。この試験項目の重要度は 3 です。

前提条件

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


System V のランレベル

従来の System V のランレベルは、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) を共通して使用します。ランレベルについては、各ディストリビューションのマニュアルを調べてください。


System V のデフォルト・ランレベル

デフォルト・ランレベルは、Linux システムの起動時に、/etc/inittab に含まれる id: というエントリーから判断されます。リスト 1 に、非グラフィカルのマルチユーザー・モードで実行されるように設定された Slackware システムの /etc/inittab ファイルの抜粋を示します。

リスト 1. /etc/inittab 内のデフォルト・ランレベル
# These are the default runlevels in Slackware:
#   0 = halt
#   1 = single user mode
#   2 = unused (but configured the same as runlevel 3)
#   3 = multiuser mode (default Slackware runlevel)
#   4 = X11 with KDM/GDM/XDM (session managers)
#   5 = unused (but configured the same as runlevel 3)
#   6 = reboot

# Default runlevel. (Do not set to 0 or 6)
id:3:initdefault:

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


ランレベルの変更

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

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

リスト 2. CentOS 6 をブートするための典型的な GRUB スタンザ
title CentOS (2.6.32-504.23.4.el6.x86_64)
	root (hd0,10)
	kernel /boot/vmlinuz-2.6.32-504.23.4.el6.x86_64 ro \
        root=UUID=2f60a3b4-ef6c-4d4c-9ef4-50d7f75124a2 rd_NO_LUKS \
        rd_NO_LVM LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 \
        crashkernel=128M  KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet

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

図 1. GRUB でブート選択項目を選択する
GRUB でブート選択項目を選択する画面のスクリーンショット

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

図 2. 編集対象とする kernel エントリーを選択する
編集対象とする kernel エントリーを選択する画面のスクリーンショット

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

図 3. 開始ランレベルを 3 に設定する
開始ランレベルを 3 に設定する画面のスクリーンショット

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

:

  1. LILO または GRUB 2 を使用してランレベルを変更する手順は、GRUB を使用して行う場合の手順と同じではありませんが、カーネルを起動する方法を編集するという基本原則は変わりません。他のシステムや他のディストリビューションでの GRUB 画面は、上記に示した画面とはかなり異なるかもしれませんが、通常は、操作を支援するプロンプトが表示されます。
  2. upstart または systemd のいずれかを使用するシステムでは、ランレベルはシミュレートされるため、自分が期待したまさにそのとおりには動作しない部分が出てくる可能性があります。これは、telinit を使用してランレベルを変更しようとしている場合に特に言えることです。

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

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

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

リスト4. 変更後のランレベルの確認
[ian@attic4-cent ~]$ runlevel
3 5

System V init を使用している (Slackware 37 などの) システム上で、ls コマンドを使って telinit コマンドの詳細リストを表示してみると、このコマンドは実際には init コマンドへのシンボリック・リンクであることがわかります。リスト 5 に、この詳細リストを示します。お使いのシステムで、upstart または systemd を使用している場合には、このことは当てはまりません。

root@attic4:~# # Slackware 37
root@attic4:~# ls -l $(which telinit)
lrwxrwxrwx 1 root root 4 Aug 28  2011 /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@attic4-cent ~]# shutdown 5 File system recovery needed

Broadcast message from ian@attic4-cent
	(/dev/pts/1) at 18:11 ...

The system is going down for maintenance in 5 minutes!
File system recovery needed 
^Cshutdown: Shutdown cancelled
[root@attic4-cent ~]# shutdown -r 10 Reloading updated kernel&
[1] 5667
[root@attic4-cent ~]# 
Broadcast message from ian@attic4-cent
	(/dev/pts/1) at 18:11 ...

The system is going down for reboot in 10 minutes!
Reloading updated kernel 
fg
shutdown -r 10 Reloading updated kernel
^Cshutdown: Shutdown cancelled
[root@attic4-cent ~]# shutdown -h 23:59&
[1] 5669
[root@attic4-cent ~]# 
Broadcast message from ian@attic4-cent
	(/dev/pts/1) at 18:11 ...

The system is going down for halt in 348 minutes!

[root@attic4-cent ~]# shutdown -c
shutdown: Shutdown cancelled
[1]+  Done                    shutdown -h 23:59

最後の例では、18:11 にブロードキャスト・メッセージが送信されましたが、6.5 時間ぐらい後の 23:59 にシャットダウンを要求していることに注目してください。従来の System V でのシャットダウンの実装では、シャットダウンまでの時間が 15 分を超えている場合には警告メッセージは送信されず、予定されたシャットダウンの 15 分前になるまで待ってからメッセージが送信されます。リスト 7 に Slackware 37 上での System V の例と、SIGTERM シグナルを送ってから SIGKILL シグナルを送るまでのデフォルト遅延を 5 秒から 60 秒に延ばすために -t オプションを使用する方法を示します。

リスト 7. 別のシャットダウンの例
root@attic4:~# date;shutdown -t60 17 Time to do backups&
Tue Jul 14 18:27:08 EDT 2015
[1] 2240
root@attic4:~#
Broadcast message from root (tty1) (Tue Jul 14 18:29:08 2015):

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

wall を使用してユーザーに通知する

シャットダウンをキャンセルするとしたら、wall コマンドを使用して、すべてのユーザーに警告を送信し、システムは停止されないことを通知してください。wall コマンドは、コマンドライン上でパラメーターとして警告を取るか、ファイルからメッセージを送信するかのいずれかを行います。複数行のメッセージを送信するには、echo -e を使用して、その出力を wall にパイプするのが簡単な方法です。リスト 8 にこの様子を示します。

リスト 8. wall を使用してユーザーに警告する
[root@atticf22 ~]# wall Scheduled outage at 23:59 has been canceled
                                                                               
Broadcast message from ian@atticf22 (pts/1) (Tue Jul 14 21:07:05 2015):        
                                                                               
Scheduled outage at 23:59 has been canceled
                                                                               
[root@atticf22 ~]# echo -e "We are experiencing system problemsOutage rescheduled to 02:30" | wall
                                                                               
Broadcast message from ian@atticf22 (pts/1) (Tue Jul 14 21:07:36 2015):        
                                                                               
We are experiencing system problems                                            
Outage rescheduled to 02:30

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

突然のシステム停止でユーザーを困らせたくなければ、wall を使用してユーザーに通知する必要があります。その他のすべての手段は、好きなようにすることができます。


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

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

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

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

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


System V の /etc/inittab

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

リスト 9. Slackware 37 の inittab ファイルの全容
#
# inittab	This file describes how the INIT process should set up
#		the system in a certain run-level.
#
# Version:	@(#)inittab		2.04	17/05/93	MvS
#                                       2.10    02/10/95        PV
#                                       3.00    02/06/1999      PV
#                                       4.00    04/10/2002      PV
#                                      13.37    2011-03-25      PJV
#
# Author:	Miquel van Smoorenburg, <miquels@drinkel.nl.mugnet.org>
# Modified by:	Patrick J. Volkerding, <volkerdi@slackware.com>
#

# These are the default runlevels in Slackware:
#   0 = halt
#   1 = single user mode
#   2 = unused (but configured the same as runlevel 3)
#   3 = multiuser mode (default Slackware runlevel)
#   4 = X11 with KDM/GDM/XDM (session managers)
#   5 = unused (but configured the same as runlevel 3)
#   6 = reboot

# Default runlevel. (Do not set to 0 or 6)
id:3:initdefault:

# System initialization (runs when system boots).
si:S:sysinit:/etc/rc.d/rc.S

# Script to run when going single user (runlevel 1).
su:1S:wait:/etc/rc.d/rc.K

# Script to run when going multi user.
rc:2345:wait:/etc/rc.d/rc.M

# What to do at the "Three Finger Salute".
ca::ctrlaltdel:/sbin/shutdown -t5 -r now

# Runlevel 0 halts the system.
l0:0:wait:/etc/rc.d/rc.0

# Runlevel 6 reboots the system.
l6:6:wait:/etc/rc.d/rc.6

# What to do when power fails.
pf::powerfail:/sbin/genpowerfail start

# If power is back, cancel the running shutdown.
pg::powerokwait:/sbin/genpowerfail stop

# These are the standard console login getties in multiuser mode:
c1:12345:respawn:/sbin/agetty 38400 tty1 linux
c2:12345:respawn:/sbin/agetty 38400 tty2 linux
c3:12345:respawn:/sbin/agetty 38400 tty3 linux
c4:12345:respawn:/sbin/agetty 38400 tty4 linux
c5:12345:respawn:/sbin/agetty 38400 tty5 linux
c6:12345:respawn:/sbin/agetty 38400 tty6 linux

# Local serial lines:
#s1:12345:respawn:/sbin/agetty -L ttyS0 9600 vt100
#s2:12345:respawn:/sbin/agetty -L ttyS1 9600 vt100

# Dialup lines:
#d1:12345:respawn:/sbin/agetty -mt60 38400,19200,9600,2400,1200 ttyS0 vt100
#d2:12345:respawn:/sbin/agetty -mt60 38400,19200,9600,2400,1200 ttyS1 vt100

# Runlevel 4 also starts /etc/rc.d/rc.4 to run a display manager for X.
# Display managers are preferred in this order:  gdm, kdm, xdm
x1:4:respawn:/etc/rc.d/rc.4

# End of /etc/inittab

いつもの如く、# で始まる行はコメントです。その他の行には、複数のフィールドが以下の形式で記載されています。
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 を押したときなど)、関連付けられたプロセスを実行します。

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

リスト 10. Ctrl-Alt-Delete の捕捉
# What to do at the "Three Finger Salute".
ca::ctrlaltdel:/sbin/shutdown -t5 -r now

System V の初期化スクリプト

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

# Script to run when going multi user.
rc:2345:wait:/etc/rc.d/rc.M

上記の例では、ランレベル 2、3、4、または 5 が入力される場合には、init が必ず /etc/rc.d/M スクリプト (コマンド) を実行することになります。init はこのコマンドが完了するまで、別の操作を行いません。

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

リスト 11. 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 の後ということになります。K のリンクと S のリンクは、通常は同じスクリプトにリンクされているため、そのスクリプトではリンクがあるレベルに入るものであるか、それともあるレベルから抜けるものであるかを知るために、スクリプトを呼び出したリンク名を検証します。

ただし、Slackware ではリスト 12 に示すように、それとは少し異なる方法を用いています。/etc/rc[0-9].d ディレクトリーはすべて空であることに注目してください。特定のランレベルに入るのは、スクリプトによって制御されます。例えば、ランレベル 2、3、4、または 5 に入るときに使用される、マルチユーザー・モードにするためのスクリプト /etc/rc.d/rc.M などです。

リスト 12. Slackware 37 Init スクリプト
root@attic4:~# find /etc/rc[0-9].*
/etc/rc0.d
/etc/rc1.d
/etc/rc2.d
/etc/rc3.d
/etc/rc4.d
/etc/rc5.d
/etc/rc6.d
root@attic4:~# ls /etc/rc.*/???a*
/etc/rc.d/rc.acpid*  /etc/rc.d/rc.atalk
/etc/rc.d/rc.alsa*   /etc/rc.d/rc.autofs

上記例で /etc/init.d/autofs を指すシンボリック・リンクである /etc/rc.d/rc2.d/K72autofs および /etc/rc.d/rc4.d/S28autofs と /etc/rc.d/rc.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 について説明します。

システム初期化がどのようになっているかがわからない場合には、システム上で起動される最初のプロセスがプロセス ID (PID) 1 になることを覚えておいてください。そして、どのプログラムが PID1 として実行されているかを調べてください。そのプログラムが init と呼ばれるものである場合、どのパッケージによって提供されているかを突き止めます。リスト 13 に、いくつかのシステムでこれを行う方法を示します。

リスト 13. init を提供するパッケージを調べる
[ian@atticf22 lpic-1]$ # Fedora 22
[ian@atticf22 lpic-1]$ ps -p 1 -o comm=
systemd
[ian@atticf22 lpic-1]$ # Ah! It's systemd

ian@attic4:~$ # Slackware 37
ian@attic4:~$ ps -p 1 -o comm=
init
ian@attic4:~$ grep  sbin/init /var/log/packages/*
/var/log/packages/sysvinit-2.86-x86_64-6:sbin/init.new
/var/log/packages/sysvinit-2.86-x86_64-6:sbin/initscript.sample
/var/log/packages/sysvinit-functions-8.53-x86_64-2:sbin/initlog
ian@attic4:~$ # System V style init

ian@attic-u14:~$ # Ubuntu 14
ian@attic-u14:~$ ps -p 1 -o comm=
init
ian@attic-u14:~$ dpkg -S `which init`
upstart: /sbin/init
ian@attic-u14:~$ # Upstart

ian@yoga-u15:~$ # Ubuntu 15.04
ian@yoga-u15:~$ ps -p 1 -o comm=
systemd
ian@yoga-u15:~$ # Ubuntu has switched from upstart to systemd

[ian@attic4-cent ~]$ # CentOS 6
[ian@attic4-cent ~]$ ps -p 1 -o comm=
init
[ian@attic4-cent ~]$ rpm -q --whatprovides `which init`
upstart-0.6.5-13.el6_5.3.x86_64
[ian@attic4-cent ~]$ # Another upstart system

upstart と systemd のどちらを使用するとしても、System V Init の名残があります。これは特に、/etc/fstab とスケルトンである /etc/inittab について言えます。ランレベルの概念は、直接はサポートされておらず、telinit などの System V コマンドはサポートされていますが、それらの機能は内部で upstart ジョブや systemd ユニットのアクティベーションおよびディアクティベーションにマッピングされます。言うまでもないことですが、このマッピングは場合によっては完璧ではないかもしれず、ランレベル 3 にブートしてから telinit を使用してランレベル 5 に切り替えた場合、リブートしたときとまったく同じようにシステムが動作することもあれば動作しないこともあります。「SysVinit to Systemd Cheatsheet」(「参考文献」を参照) は、この概念とコマンドを System V init から 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 プロセスの再起動などを行うことができます。例として、リスト 14initctl を使用して Ubuntu 14 システム上の upstart ジョブの一覧を取得する方法を示します。

リスト 14. initctl コマンドによる upstart の init デーモンの操作
ian@attic-u14:~/data/lpic-1$ # Ubuntu 14
ian@attic-u14:~/data/lpic-1$ initctl list
gnome-keyring-gpg stop/waiting
indicator-application start/running, process 1935
unicast-local-avahi stop/waiting
update-notifier-crash stop/waiting
update-notifier-hp-firmware stop/waiting
xsession-init stop/waiting
dbus start/running, process 1734
update-notifier-cds stop/waiting
gnome-keyring-ssh stop/waiting
gnome-session (Unity) start/running, process 1802
ssh-agent stop/waiting
unity7 stop/waiting
unity-voice-service stop/waiting
upstart-dbus-session-bridge start/running, process 1837
indicator-messages start/running, process 1884
logrotate stop/waiting
indicator-bluetooth start/running, process 1885
unity-panel-service start/running, process 1835
hud start/running, process 1798
im-config start/running
unity-gtk-module stop/waiting
session-migration stop/waiting
upstart-dbus-system-bridge start/running, process 1789
at-spi2-registryd start/running, process 1801
indicator-power start/running, process 1889
update-notifier-release stop/waiting
indicator-datetime start/running, process 1891
unity-settings-daemon start/running, process 1794
indicator-sound start/running, process 1894
upstart-file-bridge start/running, process 1790
gnome-keyring stop/waiting
window-stack-bridge start/running, process 1754
indicator-printers start/running, process 1902
re-exec stop/waiting
upstart-event-bridge start/running, process 1745
unity-panel-service-lockscreen stop/waiting
indicator-session start/running, process 1918

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


systemd

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

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

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

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

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

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

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

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

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

リスト 16. systemctl コマンドの出力の抜粋
[ian@atticf22 ~]$ systemctl --no-pager
  UNIT                          LOAD   ACTIVE SUB       DESCRIPTION
  proc-sys-fs-binfmt_misc.automount loaded active running   Arbitrary Executable File Form
  sys-devices-pci0000:00-0000:00:02.0-0000:01:00.1-sound-card1.device loaded active plugged   
GF119 HDMI Audio Controller
  sys-devices-pci0000:00-0000:00:06.0-0000:03:00.0-net-enp3s0.device loaded active plugged   
RTL8111/8168/8411 PCI Express 
  sys-devices-pci0000:00-0000:00:11.0-ata1-host0-target0:0:0-0:0:0:0-block-sda-sda1.device 
loaded active plugged   WDC_WD6401AALS-00L3B2 /grubfil
...
  sys-devices-pci0000:00-0000:00:11.0-ata1-host0-target0:0:0-0:0:0:0-block-sda-sda9.device 
loaded active plugged   WDC_WD6401AALS-00L3B2 9
  sys-devices-pci0000:00-0000:00:11.0-ata1-host0-target0:0:0-0:0:0:0-block-sda.device 
loaded active plugged   WDC_WD6401AALS-00L3B2
...
  sys-devices-pci0000:00-0000:00:12.2-usb1-1\x2d6-1\x2d6:1.2-sound-card2.device loaded 
active plugged   Webcam C310
  sys-devices-pci0000:00-0000:00:14.1-ata6-host5-target5:0:0-5:0:0:0-block-sr0.device loaded 
active plugged   Optiarc_DVD_RW_AD-7240S
...
  sys-module-configfs.device    loaded active plugged   /sys/module/configfs
  sys-module-fuse.device        loaded active plugged   /sys/module/fuse
...
  sys-subsystem-net-devices-enp3s0.device loaded active plugged   RTL8111/8168/8411 PCI Express 
  sys-subsystem-net-devices-virbr0.device loaded active plugged   /sys/subsystem/net/devices/vir
  sys-subsystem-net-devices-virbr0\x2dnic.device loaded active plugged   /sys/subsystem/net/devices/vir
  -.mount                       loaded active mounted   /
...
  cups.path                     loaded active waiting   CUPS Scheduler
  systemd-ask-password-plymouth.path loaded active waiting   Forward Password Requests to P
  systemd-ask-password-wall.path loaded active waiting   Forward Password Requests to W
  session-1.scope               loaded active abandoned Session 1 of user ian
  session-2.scope               loaded active running   Session 2 of user ian
  session-c1.scope              loaded active running   Session c1 of user gdm
...
  crond.service                 loaded active running   Command Scheduler
  cups.service                  loaded active running   CUPS Scheduler
  dbus.service                  loaded active running   D-Bus System Message Bus
  dracut-shutdown.service       loaded active exited    Restore /run/initramfs on shut
  fedora-import-state.service   loaded active exited    Import network configuration f
  fedora-readonly.service       loaded active exited    Configure read-only root suppo
...
● mcelog.service                loaded failed failed    Machine Check Exception Loggin
  NetworkManager.service        loaded active running   Network Manager
  nfs-config.service            loaded active exited    Preprocess NFS configuration
  packagekit.service            loaded active running   PackageKit Daemon
...
  cups.socket                   loaded active running   CUPS Scheduler
  dbus.socket                   loaded active running   D-Bus System Message Bus Socke
  dm-event.socket               loaded active listening Device-mapper event daemon FIF
...
  sockets.target                loaded active active    Sockets
  sound.target                  loaded active active    Sound Card
  swap.target                   loaded active active    Swap
  sysinit.target                loaded active active    System Initialization
  timers.target                 loaded active active    Timers
  dnf-makecache.timer           loaded active waiting   dnf makecache timer
  systemd-tmpfiles-clean.timer  loaded active waiting   Daily Cleanup of Temporary Dir

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.

164 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

ユニット名の最後の部分 (device、path、target など) は、ユニット・タイプを表しています。

systemctl コマンドを使用すれば、システムのユニットを調べることや、制御することができます。リスト 17 に例を 2、3 個示します。この例では、最初に SSH サーバー・デーモン (sshd.service) を調べた後、このデーモンを停止してから、再度このデーモンのステータスを調べます。そして最後に、このデーモンをもう一度起動します。

リスト 17. systemctl のいくつかのアクション
[root@atticf22 ~]# # Fedora 22
[[root@atticf22 ~]# systemctl status sshd.service
● sshd.service - OpenSSH server daemon
   Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: disabled)
   Active: active (running) since Wed 2015-07-15 10:24:03 EDT; 5h 42min ago
     Docs: man:sshd(8)
           man:sshd_config(5)
 Main PID: 765 (sshd)
   CGroup: /system.slice/sshd.service
           └─765 /usr/sbin/sshd -D

Jul 15 10:24:03 atticf20 systemd[1]: Started OpenSSH server daemon.
Jul 15 10:24:03 atticf20 systemd[1]: Starting OpenSSH server daemon...
Jul 15 10:24:03 atticf20 sshd[765]: Server listening on 0.0.0.0 port 22.
Jul 15 10:24:03 atticf20 sshd[765]: Server listening on :: port 22.
[root@atticf22 ~]# systemctl stop sshd.service
[root@atticf22 ~]# systemctl status sshd.service
● sshd.service - OpenSSH server daemon
   Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: disabled)
   Active: inactive (dead) since Wed 2015-07-15 16:06:28 EDT; 3s ago
     Docs: man:sshd(8)
           man:sshd_config(5)
  Process: 765 ExecStart=/usr/sbin/sshd -D $OPTIONS (code=exited, status=0/SUCCESS)
 Main PID: 765 (code=exited, status=0/SUCCESS)

Jul 15 10:24:03 atticf20 systemd[1]: Started OpenSSH server daemon.
Jul 15 10:24:03 atticf20 systemd[1]: Starting OpenSSH server daemon...
Jul 15 10:24:03 atticf20 sshd[765]: Server listening on 0.0.0.0 port 22.
Jul 15 10:24:03 atticf20 sshd[765]: Server listening on :: port 22.
Jul 15 16:06:28 atticf22 systemd[1]: Stopping OpenSSH server daemon...
Jul 15 16:06:28 atticf22 systemd[1]: Stopped OpenSSH server daemon.
[root@atticf22 ~]# systemctl start sshd.service

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

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

参考文献

学ぶために

  • developerWorks Premium のメンバーになると、強力なツールや Safari Books Online から集めて管理する技術ライブラリーをすべて自由に利用できるほか、カンファレンスの割引を受けることや、カンファレンスの記録を閲覧することができ、さらには SoftLayer や Bluemix を利用できるクレジットが提供されるなど、さまざまな特典があります。
  • 2015年 4月時点での LPI のバージョン 4.0 の試験項目に基づく LPIC-1 認定に備えて勉強するのに役立つ developerWorks のチュートリアルを見つけるには、developerWorks の LPIC-1 ロードマップを利用してください。
  • Linux Professional Institute の Web サイトで、LPIC の詳細な試験項目、課題のリスト、例題を調べてください。特に以下のページを参照してください。 必ず Linux Professional Institute の Web サイトで最新の項目を参照してください。
  • Linux BootPrompt-HowTo は、ブート・パラメーターを理解するのに役立ちます。
  • upstart の詳細については、upstart の概要を参照してください。
  • systemd の理論的根拠に関する詳細は、「Rethinking PID 1」を参照してください。
  • SysVinit to Systemd Cheatsheet」は、System V の概念およびコマンドと、それらに相当する systemd との間のマッピングをするのに役立ちます。
  • Linux JF (Japanese FAQ) Project には、Linux に関する HOWTO 文書をはじめ、各種の有益な文書が豊富に揃っています。
  • さまざまな IBM 製品や IT 業界のトピックに焦点を絞った developerWorks テクニカル・イベントで最新の技術情報を入手してください。
  • Twitter で developerWorks をフォローしてください。

議論するために

  • developerWorks コミュニティーに参加してください。ここでは他の developerWorks ユーザーとのつながりを持てる他、開発者によるブログ、フォーラム、グループ、Wiki を調べることができます。

コメント

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=1034662
ArticleTitle=Linux の 101 試験対策: ランレベル、ブート・ターゲット、シャットダウン、リブート
publish-date=07072016