イントロダクション
Linux システムの起動プロセスの概要
SysVinit の概要と使用方法
イベント駆動型の起動メカニズムの概要と使用方法
systemd の概要と使用方法
システムの起動とスクリプトの実行をモニターする
まとめ
ダウンロード可能なリソース
関連トピック
コメント

Linux システムの起動プロセスをカスタマイズしてモニターする

Linux の各種の起動メカニズムを比較する

William von Hagen
配信 2014年 6月 05日

Linux システムの起動プロセスの概要

Linux システムの起動プロセス (電源を入れてからシステムが完全に稼働している状態になるまでのプロセス) は、以下に記載する 2 つの概念フェーズで構成されているとみなすことができます。

デバイスからブートし、Linux カーネルをロードして初期化する
ユーザー空間のアプリケーション (サーバー・プロセスを含む) を起動して、追加のファイル・システムをマウントし、追加のカーネル構成とカスタマイズを実行し、その他のデバイスにアクセスできるようにする

最初のフェーズの基本ステップは、以前の developerWorks 記事「Inside the Linux Boot Process」(「参考文献」を参照) で説明しています。その当時から、基本ステップはほとんど変わっていません。異なる点は、GRUB 2 (GRand Unified Bootloader 2) が使用されるようになったこと、初期 RAM ディスクのフォーマットと使用法が変更されたこと、そして最初に起動されるユーザー空間プロセス (従来の init プロセス) に変更が加えられたことだけです。最初のフェーズでのパフォーマンスの向上は、主にハードウェアが進化したことによって実現されています。例えば、ブート・デバイスやデバイス・アクセス・メカニズムが高速化されたこと、プロセッサーが高速化されて強力になったことなどです。一方、2 番目のフェーズでのパフォーマンスの向上は、ほぼ完全にソフトウェアに依存するものであり、この分野では、さまざまな手法を使用した取り組みが続けられています。

フェーズ 2 のシステム起動時間を短縮する簡単な方法は、Linux 起動プロセスの 2 番目のフェーズを実行するメカニズムのパフォーマンスを向上させることですが、起動シーケンス自体を変更することで、それよりもはるかに大きな起動時間の短縮が実現されます。フェーズ 2 のシステム起動時間を短縮する上で重要な領域には、以下のものがあります。

最小化: 最小限必要なサービスだけを起動します。
線形性: ある 1 つのサービスの要件のうち、他の (1 つまたは複数の) サービスに対する要件を理解して (「依存関係分析」とも呼ばれます)、起動プロセス中にそれらの要件を考慮に入れることを意味します。
並列性: 同時に起動可能な、独立したサービス (または関連するサービスのチェーン) の範囲を最大限にすることを意味します。

Linux はその歴史全体を通して、さまざまな起動およびシャットダウン・メカニズムを使用して、後方互換性をまったく妨げることなく線形性と並列性のバランスを取るよう努めてきました。以降のセクションでは、最もよく使われているメカニズムをいくつか取り上げ、システム上でそのメカニズムの動作とパフォーマンスをモニターすることで、最適化の可能性を見極められるようにする方法を説明します。

SysVinit の概要と使用方法

Linux システムで従来から使用されているシステム起動およびシャットダウン・メカニズムは、SysVinit として知られています。この名前からわかるように、SysVinit メカニズムの概念上のルーツは、1989年にリリースされた UNIX の Sys V バージョン (正式には、UNIX System V, Release 4 (SVR4)) にあります。SysVinit の init プログラムは /etc/inittab ファイルを読み取り、システムがデフォルト状態 (システムのデフォルト「ランレベル」と呼ばれます) に達するために使用可能になっていなければならない一連のサービスと、その状態に達するために実行する必要があるコマンドを特定します。SysVinit を使用するシステムは、これらの情報を /etc/inittab ファイルのエントリーによって定義します (リスト 1 を参照)。

リスト 1. /etc/inittab 内に定義された従来の起動関連のコマンド

si::sysinit:/etc/init.d/rcS
id:5:initdefault:
l5:5:wait:/etc/init.d/rc 5

1 行目に示されているのは、システムの初期化時にシステムが最初に実行する必要があるスクリプトです。2 行目では、初期化後のシステムのデフォルト・ランレベルが指定されています。この例では、デフォルト・ランレベルは 5 になっています。これは一般に、完全なネットワーキング機能とグラフィカル機能を使用できるシステムを意味します。3 行目では、ランレベル 5 に達するためにシステムが使用する必要があるコマンドを指定しています。

SysVinit を使用する場合、/etc/init.d ディレクトリーにはシステム・レベルのすべてのプロセスについて、プロセスを開始および停止するためのシェル・スクリプトが含まれています。/etc ディレクトリーにはランレベルに固有のディレクトリーがあり、そこにはそのランレベルに入るときや、そのランレベルから抜けるときに、開始または停止する必要がある (/etc/init.d ディレクトリー内の) シェル・スクリプトへのシンボリック・リンクが含まれています。リスト 1 の 3 行目は、SysVinit メカニズムに対し、ランレベル 5 に関連付けられたディレクトリー内のスクリプトを実行するように指示しています。このディレクトリーは一般に、実行している Linux ディストリビューションによって /etc/rc5.d、/etc/init.d/rc5.d、または /etc/rc.d/rc5.d のいずれかになります。

ランレベル・ディレクトリー内のシンボリック・リンクは、S または K で始まります。これらの文字は、指定されたランレベルにシステムが入るときに、関連付けられたシステム・プロセスを開始 (S) するためにこのシンボリック・リンクを実行する必要があるのか、それともそのランレベルから抜けるときにシステム・プロセスを終了 (K) するためにこのシンボリック・リンクを実行する必要があるのかを示しています。S または K の後に続く整数値は、そのランレベルに入るとき、またはそのランレベルから抜けるときに実行する必要があるスクリプトの実行順序を指定します。

新しいスクリプトを /etc/init.d ディレクトリーに追加するときには、各スクリプトの先頭にある特殊なフォーマットのコメントで、そのスクリプトが依存するその他すべてのスクリプトと、そのスクリプトを関連付ける必要がある各ランレベルを指定します。これらのスクリプトに存在していなければならないコマンドとその他の情報は、LSB (Linux Standard Base) 仕様の一部として定義されています。LSB は、さまざまな Linux ディストリビューションで SysVinit スクリプトの互換性を確保するために、複数の Linux ディストリビューションによって開発された標準です。リスト 2 (init スクリプトのコメントに関する LSB の解説から抜粋) に、該当するセクションの例を示します。

リスト 2. 従来の SysVinit スクリプトに含まれるコメント・ブロック

### BEGIN INIT INFO
# Provides: lsb-ourdb
# Required-Start: $local_fs $network $remote_fs
# Required-Stop: $local_fs $network $remote_fs
# Default-Start:  2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: start and stop OurDB
# Description: OurDB is a very fast and reliable database
# engine used for illustrating init scripts
### END INIT INFO

表 1 に、上記リストの各エントリーによって指定される情報の説明を記載します。

表 1. SysVinit スクリプトに含まれる INIT INFO セクション内のコメント

キーワード	意味
`Provides`	この初期化スクリプトが指定するサービスの論理名。
`Required-Start`	この初期化スクリプトで定義しているサービスを正常に開始する上で実行状態になっていなければならない、その他のサービスの論理名。
`Required-Stop`	この初期化スクリプトで定義しているサービスを正常に停止する上で実行状態になっていなければならない、その他のサービスの論理名。
`Default-Start`	この初期化スクリプトで定義しているサービスを開始するために、この初期化スクリプトを実行する必要があるランレベル。
`Default-Stop`	この初期化スクリプトで定義しているサービスを停止するために、この初期化スクリプトを実行する必要があるランレベル。
`Short-Description` および `Description`	初期化スクリプト内のコマンドに関連付けられたサービスの概略および詳しい説明。これらの説明は、各種のシステム・ユーティリティーで SysVinit 初期化スクリプトを照会および要約するために使用されます。

/sbin/service コマンドを使用すると、SysVinit スクリプトを開始、停止、一覧表示することができます。/sbin/chkconfig コマンドを使用すると、SysVinit スクリプトが関連付けられているランレベルを一覧表示または変更することができます。

システムの起動にシェル・スクリプトを使用すると、システムの起動プロセスに新しいコマンドを追加したり、サービスを開始または停止するときに実行するアクションを変更したりするのが簡単になります。また、ブート・シーケンスの特定の時点で実行する新規サービスを追加する場合も、そのサービスへのシンボリック・リンクを作成して、シンボリック・リンクの名前に適切な番号を指定するだけで済みます。

パフォーマンスの観点では、SysVinit は特定のランレベルに到達するために、複数のシェル・スクリプトを指定された順序で実行します。シェル・スクリプトの実行には比較的時間がかかるだけでなく、これは本質的にシーケンシャルの起動メカニズムです。従って、並列処理の可能性があってもそれを利用する手段がないことから、ブート時間を長引かせることになります。ターゲットのランレベルに関連付けられた各シェル・スクリプトを、そのスクリプトを指すシンボリック・リンクの名前に指定された番号の順番で実行しなければならないため、現行のスクリプトが完了するまでは、別のサービスの起動を開始することができません。これらの理由から、この記事の最後のセクション「システムの起動とスクリプトの実行をモニターする」で説明している起動モニターおよびプロファイリング・ツールを統合し、各起動スクリプトの実行に要している時間を正確に判断することによって、SysVinit を使用するシステムは最大限のメリットを得ることができます。

SysVinit メカニズム全般についての詳しい説明については、developerWorks 記事「Boot Linux Faster」を参照してください (「参考文献」を参照)。

イベント駆動型の起動メカニズムの概要と使用方法

SysVinit はシェル・スクリプトを使用してシステム・サービスの開始と停止を行うことから、操作しやすく、変更するのも簡単です。その一方で、シーケンシャル・シェル・スクリプトを使用するという性質上、SysVinit は処理を実行するのに時間がかかる上に、関連のない複数のサービスを並列に開始することはできません。さらに、サービスを開始および停止するスクリプトは、システムの起動時およびシャットダウン時にしか実行されないという問題があります。つまり、これらのスクリプトは、システムのランレベルが変更されたときのイベントにしか応答しません。わずかな例外 (他のサービスによって開始されるサービスなど) を除けば、これは、システムで必要となる可能性のあるすべてのサービスが常に実行状態になっていて、受信されない可能性があるリクエストを待機しなければならないことを意味します。

使用されないプロセスを実行することは、メモリーおよびプロセッサーのリソース使用という観点でも、そもそもプロセスを開始するために必要となる時間の観点でも、非効率的です。ますます柔軟になってきている最近のシステムは、さまざまな状況で (例えば、ネットワーク接続が有線から無線に変更された後や、ネットワーク間でマイグレーションが行われた後、あるいはストレージ・デバイスやその他の周辺機器の追加や除去でハードウェアが変更された後でも) 正常かつシームレスに機能できる必要があります。

そこで、イベント駆動型の起動メカニズムが登場します。このメカニズムは、まさにその名のとおり、あるイベントがシステム上で発生すると、特定のコマンドを実行して関連するサービスを開始します。各種ネットワーク・サービスの inetd デーモンと xinetd デーモンは、イベント駆動型の起動メカニズムの好例です。というのも、これらのデーモンは、特定のイベント (管理対象のサービスへのネットワーク接続リクエスト) が発生するまでただ待機し、必要に応じて該当するサービスを開始するためです。イベント駆動型の起動メカニズムは、イベントに応じて同時に複数のコマンドを実行可能にすることで、システム起動中の並列性を最大限に引き出します。そして、この動的応答性をシステムのランタイム環境にまで拡張します。これらのイベントは基本的に、プロセスがモニターしている対象の状態が変更されたときの応答として送信できるストリング・メッセージです。イベント・メッセージは、プロセスによって 1 回送信されます。

最もよく知られているイベント駆動型の起動メカニズムは、Upstart です。Upstart はデフォルトの起動メカニズムとして、Ubuntu 9.10 以降のバージョンや、RHEL6 と関連ディストリビューション (CentOS、Oracle Linux、Scientific Linux など)、Fedora 9-14、その他多くの Linux ディストリビューションで使用されています。Upstart は SysVinit ランレベル・モデルとの後方互換性を提供します。

Upstart は、ジョブ構成 (conf) ファイルと呼ばれるファイルを使用して、起動、シャットダウン、ランレベル (ランレベルの遷移) などのイベントに対する応答を識別します。これらのファイルは、レガシーな理由で /etc/event.d ディレクトリーに配置されるものもありますが、通常は /etc/init ディレクトリーに配置されます。新しく作成するシステム全体の conf ファイルは、/etc/init ディレクトリーに配置してください。通常、conf ファイルは .conf 拡張子が付けられたテキスト・ファイルであり、少なくとも以下の情報を含んでいる必要があります。

conf ファイルが何らかのアクションを実行する必要がある 1 つ以上のイベント。例えば、start on startup エントリーには startup イベントの受信時にジョブ・ファイルを実行する必要があることを記述し、stop on runlevel エントリーには runlevel イベントの受信時 (例えば、システムのランレベルが変更された時点など) にジョブ・ファイルを停止する必要があることを記述します。
少なくとも 1 つの exec エントリーが含まれる task または respawn セクション、またはこのジョブ・ファイルをトリガーするイベントに応答して実行されるコマンドを識別する script セクション。exec エントリーは、特定のコマンドライン引数のセットを指定して、特定のコマンド (通常は、バイナリー) を実行します。「スタンザ」と呼ばれる script セクションには、あらゆるシェル・スクリプトと同じように、シェルが実行するコマンドを指定します。このセクションは、end script 文で終了しなければなりません。 Upstart は、task キーワードと respawn キーワードによって、ジョブの 2 つの概念クラスを次のように管理します。
- タスクは完了しなければなりません。つまり、タスクは停止状態から開始された状態に遷移し、完了後に停止状態に戻らなければなりません。
- サービスは常に実行中でなければなりません。従って、サービスは停止状態から開始された状態にしか遷移しません。respawn セクションは、サービスの開始方法と再開方法の両方を識別します。

Upstart conf ファイルの task セクションでは、出力デバイスを識別するために他のキーワードを使用することや、主要な exec セクションまたは script セクションが実行される前に実行するスクリプトを記述することや、主要な exec セクションまたは script セクションが完了した後に実行するスクリプトを記述することができます。pre-start script セクションには、script コマンドまたは exec コマンドに必要な環境を初期化するために使用するコマンドを指定する一方、post-stop script セクションには、exec コマンドまたは script スタンザが完了した後で、クリーンアップするためや事後処理を実行するために使用するコマンドを指定します。ジョブ・ファイルでは、他にも多くの Upstart コマンドを使用することができます (「参考文献」を参照)。

一例として、リスト 3 に、SysVinit メカニズムをエミュレートする /etc/init/rcS.conf Upstart ジョブ・ファイルを記載します。読みやすくするために、コメントは削除してあります。

リスト 3. /etc/init/rcS.conf Upstart ジョブ・ファイル

start on runlevel [0123456]

stop on runlevel [!$RUNLEVEL]

task

export RUNLEVEL
console output
exec /etc/rc.d/rc $RUNLEVEL

この conf ファイルは、現在のランレベルに関連付けられたディレクトリー内にある既存の SysVinit スクリプトを実行するタスクを定義します。

/sbin/initctl コマンドを使用すると、Upstart ジョブを開始、停止、一覧表示することができます。このコマンドは、現在実行中の Upstart ジョブと、それぞれの現在の状態を表示します。システムの初期化シーケンスに新しいジョブを追加するには、単にそのサービスの適切な conf ファイルを作成して、そのファイルを /etc/init ディレクトリーにインストールします。Upstart バージョン 1.3 以降では、ユーザーのホーム・ディレクトリーの .init サブディレクトリーに置かれたユーザー固有の conf ファイルもサポートするようになっています。ただし、このオプションは通常、有効にはされていません。

`systemd` の概要と使用方法

Upstart によって Linux システムから SysVinit が一掃されると思われたときに、Upstart よりも優れていて有望かつ効率的な起動メカニズムが新たに登場しました。それは、Leonard Poettering 氏によって最初に作成された systemd (システム・デーモン) です。systemd のシステム起動メカニズムは、各種のサービスが必要なものとして使用する基本リソースを理解することにより、システムの起動プロセスの並列化を大幅に改善します。さらに、systemd は、カーネル 2.6 以降の Linux カーネルでサポートされている制御グループ (cgroups) メカニズムを使用することで、関連するプロセスのリソースを簡単に追跡し、管理できるようにします。

最近の Linux サービスおよび関連するクライアントのほとんどでは、プロセス間通信 (例えば、一般的なハードウェア関連のメッセージとローカルのアプリケーション間メッセージに使用される、D-Bus メッセージ・バスなど) に UNIX ソケットを使用しています。必要なソケットが存在する場合、または D-Bus がアクティブになっている場合、それらを使用する任意のサービスを起動できるため、systemd はまず、指定されたシステム上で開始する必要があるサービスに関連付けられているすべてのソケットを作成します。これらのリソースを使用するサービスは、通常、メッセージの配信または受信が必要になるまでブロックされるため、並列に開始することも、受信されるリクエストに基づいてオンデマンドで開始することもできます。

論理リソースを作成し、それらのリソースを並列に使用可能なサービスを開始できるようにするというモデルは、クライアントとサーバーだけに限られるモデルではありません。システム起動プロセスで従来時間がかかっていた部分 (ファイル・システムの整合性チェックとマウントなど) であっても、autofs などのオンデマンド・ファイル・システム・アクセス・メカニズムと組み合わせることで、(誰もが常に必要としている) ルート・ファイル・システム以外のファイル・システムに対してこのモデルを使用することができます。ファイル・システムがマウントされると、ファイルまたはファイル・システムの変更イベントを利用して、カーネルの fanotify および fsnotify メカニズムを使用した他のアクションをトリガーすることができます。

systemd 起動メカニズムは、このメカニズムが「ユニット」として管理する任意の対象を参照します。さまざまなタイプの初期化と起動の要件を満たすために、systemd ではさまざまなタイプのユニットをサポートしています。そのなかでも、最もよく使用されるユニットを表 2 で説明します。

表 2. `systemd` でよく使用されるユニットのタイプ

ユニットのタイプ	説明
`automount`	オンデマンド・ファイル・システム・アクセス・メカニズム (`autofs` など) が使用するファイル・システム・マウント・ポイントを特定するためのユニットです。`automount` ユニットごとに、対応する `mount` ユニットがあります。
`device`	`udev` ルールの対象となる物理デバイスを表すユニットです。
`mount`	標準のファイル・システム・マウント・ポイントを特定するためのユニットです。
`service`	開始、停止、再開、再ロードなどが可能なデーモンを定義するためのユニットです。これらのアクションは、SysVinit 起動メカニズムによって実行される、従来型のアクションであるため、`systemd` は SysVinit 起動スクリプト内の LSB コメント (「SysVinit の概要と使用方法」で説明) を自動的に解析し、その情報を必要に応じて使用することができます。
`socket`	標準タイプのファイル・システムまたはネットワーク・ソケット (`AF_INET` や `AF_UNIX` など) を表すユニットです。これらのソケットへの接続要求によって関連するサービスの開始をトリガーすることができます。
`target`	概念的に関連するその他のユニットをグループ化するために使用する論理ユニットを定義するユニットです。一例として、`systemd` は、グラフィック・デバイスが使用可能になったときにグラフィック・コンソールを使用してシステム上で起動する必要があるすべてのアプリケーションを 1 つにまとめるために、`graphical.target` ユニットを使用します。

systemd でサポートしているユニットのタイプに関連付けられたサービス構成ファイルは、通常 /etc/systemd のサブディレクトリー内に配置されます。リスト 4 に、systemd サービス構成ファイルの例を示します。

リスト 4. `systemd` サービス構成ファイルの例

[Unit]
Description=System Logging Service

[Service]
EnvironmentFile=-/etc/sysconfig/rsyslog
ExecStart=/sbin/rsyslogd -n $SYSLOGD_OPTIONS
Sockets=syslog.socket
StandardOutput=null

[Install]
WantedBy=multi-user.target
Alias=syslog.service

このファイルは、Fedora 17 システムの rsyslog.service からの syslog 用のユニットを定義しており、etc/systemd/system/multi-user.target.wants ディレクトリー内にあります。ご覧のように、このファイルのセクションでは、まずこの systemd サービスに関連付けられているユニットの説明を記載し、サービスの開始方法とサービスが使用するリソースを指定するとともに、そのユニットを呼び出す条件 (この例では、システムの起動ターゲットが multi-user.target である場合) を指定しています。

systemd 起動メカニズムでは、各種のユニットを開始/停止する場合、およびそのステータスを調べる場合には、コマンドラインから systemctl コマンドを使用します。このコマンドと同じ機能をグラフィカル・インターフェースとして提供する systemadm コマンドもありますが、デフォルトではインストールされません。このコマンドを追加するには、systemd-gtk パッケージをインストールする必要があります。

systemd 起動メカニズムは顕著なパフォーマンス向上をもたらす一方で、起動シーケンスにおいて具体的に決まる特定の時点でコマンドを追加しなければならない場合には、このメカニズムを扱うのは厄介な作業になる可能性があります。systemd を個々のシステムでテストして、起動パフォーマンスが高まるかどうかを調べる価値はありますが、systemd は以前の Linux 起動メカニズムとはかなり異なることから、万人に好まれるわけではありません。「参考文献」のリンクで、systemd に反対する人の見方を参照してください。新しい手法はそもそも興味深いものですが、新しさが色褪せるのもあっという間のことです。

システムの起動とスクリプトの実行をモニターする

システムが使用可能になるまでに必要な時間を最小限に短縮しようとしている場合、電源を入れてからシステムが使用可能になるまでの所要時間を測定するだけでは、それほど有用な情報を得られません。実際に関心がある情報は、以下のような内容の情報です。

システム起動中に、どの初期化コマンドまたはスクリプトが実行されたか？
コマンドまたはスクリプトはどのような順番で実行されたのか？
コマンドまたはスクリプトごとに要した時間はどれだけか？

システムの起動プロセスに 1 つのスクリプトを追加しているだけの場合、まず懸念する点は、そのスクリプトが実際に実行されているかどうか、そしてどの時点で実行されているかという点です。この情報を判断するための簡単な方法は、スクリプト内から /usr/bin/logger コマンドを呼び出すことです。logger コマンドは、優先度を指定してメッセージをシステム・ログに書き込みます。例えば、以下のコマンドは、「New script executed (新規スクリプトが実行されました)」というメッセージを alert に対応する優先度の数値を指定して書き込みます (このメッセージは常にログに記録されます)。

/usr/bin/logger -p 1 "New script executed"

新しいコマンドが実行されたことを確認するのは望ましいことですが、それよりも、すべての起動スクリプトの相対パフォーマンスや、各スクリプトの所要時間などを検証できるようにしたほうが有用です。このような情報をグラフィック形式で提供する極めて便利なユーティリティーが、Bootchart です。

Bootchart は当初シェル・スクリプトとして作成されたものですが、最新バージョンの Bootchart 2 は C 言語で作成し直されたことで、より高いパフォーマンスが実現されるようになるとともに、収集するデータに対するアプリケーション自体の影響が小さくなりました。最新バージョンの Bootchart 2 を使用できるようにするには、最新バージョンのソース・コードを取得してアプリケーションをビルドし、インストールしてから、システムをブートするために使用するブートローダー・コマンドに、このアプリケーションの呼び出しを組み込みます。Bootchart 2 をビルドしてインストールする際にシステムにインストールされていなければならないのは、git ソース・コード管理システム、make アプリケーション・コンパイル・ツール、そして gcc C コンパイラーです。この前提条件が満たされていれば、以下の手順を実行することができます。

git コマンドを使用して、Bootchart 2 のソース・コード・リポジトリーを複製します。
```
git clone https://github.com/mmeeks/bootchart
```
カレント・ディレクトリーを前のステップで作成した bootchart ディレクトリーに変更し、make コマンドを実行して Bootchart 2 の各種の構成部分をコンパイルします。
root ユーザーとして、または sudo コマンドを使用して make install コマンドを実行し、各種 Bootchart 2 アプリケーションとそれらのドキュメントをそれぞれのデフォルトの場所にインストールします。
使用しているブートローダー構成ファイルのカーネル・エントリーの末尾に、以下のコードを追加します。
```
initcall_debug printk.time=y quiet init=/sbin/bootchartd
```
GRUB ブートローダーを使用している場合には、おそらく上記のテキスト・フラグメントを /boot/grub/menu.lst ファイル内のブート・スタンザに追加することになるはずです。GRUB2 ブートローダーを使用している場合は、上記のテキスト・フラグメントを追加する場所は、おそらく /boot/grub/grub.conf ファイル内のブート・スタンザです。システム上の GRUB 構成ファイルが、grub-mkconfig や grub2-mkconfig などのコマンドを使用して自動生成される場合には、上記のテキスト・フラグメントを /etc/default/grub ファイルで指定されたデフォルトのカーネル・ブート・オプションに追加してから、実際のブートローダー構成ファイルを再生成する必要があります。

この次、システムをリブートするときに、Bootchart 2 がブート・プロセスの各ステージに関するデータを収集し、そのデータのグラフィカルな要約を PNG (Portable Network Graphics) フォーマットで生成します。この要約データは、/var/log/bootchart.tgz ファイルに保存されます。このデータの関連するグラフィック表現は、/var/log/bootchart.png ファイルに保存されます。図 1 は、ブート・プロセスのグラフィカルな表現を抜粋したものです。

図 1. Bootchart のグラフィカルなブート表現の抜粋

クリックして大きなイメージを見る

Bootchart 2 によるブート・プロセスのグラフィカルなビューの最上部には、ブート情報を収集したシステムに関する情報が要約されます。この情報には、起動プロセスの合計時間も含まれます。中央のセクションには、すべての起動プロセスのグラフィカルな表現が表示されます (図 1 は、この部分の抜粋です)。その下の 2 つのセクションには、プロセスごとの累積プロセッサー使用量と、プロセスごとの累積 I/O 使用量が示されます。

システムをリブートするたびに、ここまでで説明したファイルが上書きされます。システムの起動時に実行される各種スクリプトの実行順を変更する方法を試す場合や、各種スクリプトの内容の最適化を試みる場合、あるいはその両方を試す場合、これらの結果をより簡単に比較できるようにするには、おそらく複数のシステム・ブートからの Bootchart 2 要約データを取っておく必要があるでしょう。

Bootchart 2 の構成ファイル (/etc/bootchartd.conf) には、CUSTOM_POST_CMD 変数があります。この変数によって、Bootchart 2 がデータ・ファイルおよび関連するグラフィック・ファイルを作成した後に実行するスクリプトやその他のアプリケーションへの完全パスを指定することができます。リスト 5 のサンプル・スクリプトは、出力ファイルの名前を YYYY-MM-DD-HH-MM-HOSTNAME の形式に変更して、それらの出力ファイルを /var/log/bootchart ディレクトリーに保存するために使用することができます。

リスト 5. Bootchart 出力ファイルを固有の名前に変更するためのサンプル・スクリプト

#!/bin/bash

source /etc/bootchartd.conf

HOST=$(hostname -s)

if [ ! -d $(dirname $BOOTLOG_DEST)"/bootchart" ] ; then
    mkdir $(dirname $BOOTLOG_DEST)"/bootchart"
fi

DATE=$(date +%Y-%m-%d-%H-%M)

filebase="$DATE-$HOST"

mv $BOOTLOG_DEST $(dirname $BOOTLOG_DEST)"/bootchart/"${filebase}".tgz"

if [ "x$AUTO_RENDER" = "xyes" ] ; then
    mv ${AUTO_RENDER_DIR}/bootchart.${AUTO_RENDER_FORMAT} \
       $(dirname $BOOTLOG_DEST)"/bootchart/"${filebase}"."${AUTO_RENDER_FORMAT}
fi

Bootchart 2 は、この記事で説明した Linux システム起動メカニズムのすべてと連動し、システム起動シーケンスの各ステップに必要な時間、プロセッサー使用量、I/O 使用量に関する優れた洞察を提供します。このように提供される洞察は、システムの起動時間を最小限にするために最適化を試みる必要がある、起動シーケンスの部分を特定する上で役に立ちます。

まとめ

Linux には多数の起動メカニズムが用意されており、変更するのが簡単なものもあれば、拡張可能だが速度に主眼を置いて設計されているものもあります。この記事では、最もよく使われている 3 つの Linux 起動メカニズムの概要を説明し、それぞれの目標と実装の違いを明らかにしました。Linux ディストリビューションが異なれば、そのまますぐに使用できる起動メカニズムも異なりますが、要件に最適なパフォーマンス、柔軟性、ユーザビリティーの組み合わせが見つかるまで、簡単に別の起動メカニズムをインストールして試すことができます。

ダウンロード可能なリソース

このコンテンツのPDF

目次