LFCS: システム起動プロセスとサービスの管理 (SysVinit、Systemd、および Upstart) - パート 7
数か月前、Linux Foundation は、LFCS (Linux Foundation Certified Sysadmin) 認定資格を発表しました。これは、世界各地の個人がLinux システム上で基本から中級のシステム管理タスクを実行する認定を取得します。これには、既に実行されているシステムとサービスのサポート、直接の問題発見と分析、さらにエンジニアリング チームにいつ問題を提起するかを決定する機能が含まれます。
次のビデオでは、Linux Foundation 認定プログラムについて簡単に説明しています。
この投稿は 10 回のチュートリアル シリーズの第 7 部です。このパートでは、LFCS 認定試験に必要な Linux システムの起動プロセスとサービスを管理する方法を説明します。
Linux 起動プロセスの管理
Linux システムのブート プロセスは複数のフェーズで構成され、それぞれが異なるコンポーネントによって表されます。次の図は、ブート プロセスを簡単に要約し、関係するすべての主要コンポーネントを示しています。
マシンの電源 ボタンを押すと、マザーボードのEEPROM チップに保存されているファームウェアがPOST を初期化します(電源投入時自己テスト) を使用して、システムのハードウェア リソースの状態を確認します。 POST が完了すると、ファームウェアは MBR または EFI にある第 1 ステージ ブート ローダーを検索してロードします。最初に使用可能なディスクの パーティションを作成し、そのパーティションに制御を与えます。
MBR法
MBR は、BIOS 設定で起動可能としてマークされたディスクの最初のセクタにあり、 サイズは 512 バイトです。
- 最初の 446 バイト: ブートローダーには、実行可能コードとエラー メッセージ テキストの両方が含まれています。
- 次の 64 バイト: パーティション テーブルには、4 つのパーティション (プライマリまたは拡張) ごとにレコードが含まれています。特に、各レコードは、各パーティションのステータス (アクティブ/非アクティブ)、サイズ、開始/終了セクターを示します。
- 最後の 2 バイト: マジック ナンバーは、MBR の検証チェックとして機能します。
次のコマンドは、MBR のバックアップを実行します (この例では、/dev/sda が最初のハード ディスクです)。作成されたファイル mbr.bkp は、システムが起動できなくなるなど、パーティション テーブルが破損した場合に役立ちます。
もちろん、後で必要になったときに使用するには、それを保存して別の場所 (USB ドライブなど) に保存する必要があります。このファイルは MBR の復元に役立ち、ハードドライブのレイアウトを変更しない場合に限り、再び作業を進めることができます。
バックアップMBR
# dd if=/dev/sda of=mbr.bkp bs=512 count=1
MBRの復元
# dd if=mbr.bkp of=/dev/sda bs=512 count=1
EFI/UEFI方式
EFI/UEFI 方式を使用するシステムの場合、UEFI ファームウェアはその設定を読み取り、どの UEFI アプリケーションをどこから起動するか (つまり、どのディスクとパーティションで起動するかを決定します) EFI パーティションが存在します)。
次に第 2 ステージ のブート ローダー (別名ブート マネージャー) がロードされて実行されます。 GRUB [GRand Unified Boot] は、Linux で最も頻繁に使用されるブート マネージャーです。 2 つの異なるバージョンのうちの 1 つは、現在使用されているほとんどのシステムで見つかります。
- GRUB レガシー設定ファイル: /boot/grub/menu.lst (古いディストリビューション、EFI/UEFI ファームウェアではサポートされていません)。
- GRUB2 設定ファイル: ほとんどの場合、/etc/default/grub です。
LFCS 試験の目的は、GRUB の内部構造に関する知識を明示的に要求するものではありませんが、勇気があり、システムを台無しにする余裕がある場合は (試してみるとよいでしょう)念のため、最初は仮想マシン上で実行する必要があります。
# update-grub
変更を適用するために GRUB の設定を変更した後、root として。
基本的に、GRUB はデフォルトのカーネル とinitrd または initramfs イメージをロードします。簡単に言うと、initrd または initramfs は、実際のルート ファイルシステムをマウントするために必要なハードウェアの検出、カーネル モジュールのロード、およびデバイスの検出を実行するのに役立ちます。
実際のルート ファイルシステムが起動すると、カーネルはシステムおよびサービス マネージャー (init または systemd、プロセス ID または PID は常に 1) を実行して、通常のユーザー サービスを開始します。ユーザーインターフェイスを表示するためのスペースブートプロセス。
init と systemd は両方とも、他のデーモンを管理するデーモン (バックグラウンド プロセス) であり、最初に開始されるサービス (ブート中) および最後に終了するサービス (シャットダウン中) として機能します。
サービスの開始 (SysVinit)
Linux のランレベル の概念は、実行中のサービスを制御することによってシステムを使用するさまざまな方法を指定します。言い換えれば、ランレベルは、現在の実行状態=ランレベルでどのタスクを実行できるか (およびどのタスクが実行できないか) を制御します。
従来、この起動プロセスはSystem V UNIX で始まった規則に基づいて実行され、マシンが特定のランレベルに入るとサービスを開始および停止するスクリプトの実行コレクションをシステムが渡します。 、システムの別の実行モードです)。
各ランレベル内で、個々のサービスを実行するように設定したり、実行中の場合はシャットダウンしたりすることができます。一部の主要なディストリビューションの最新バージョンは、System V 標準から離れ、systemd (システム デーモンの略) と呼ばれる新しいサービスとシステム マネージャーを採用していますが、通常は互換性を確保するために、sysv コマンドをサポートします。これは、よく知られている sysv init ツールのほとんどを systemd ベースのディストリビューションで実行できることを意味します。
こちらもお読みください: Linux で「systemd」が「init」に置き換わる理由
システム プロセスの開始に加えて、init は /etc/inittab ファイルを参照して、入力する必要があるランレベルを決定します。
- Runlevel
説明
- 0
システムを停止します。ランレベル 0 は、システムを迅速にシャットダウンするために使用される特別な移行状態です。
- 1
s または S とも呼ばれるこのランレベルは、メンテナンス モードと呼ばれることもあります。このランレベルで開始されるサービスがある場合、そのサービスはディストリビューションによって異なります。通常、通常のシステム動作によって損なわれる可能性のある低レベルのシステム メンテナンスに使用されます。
- 2
マルチユーザー。 Debian システムおよび派生システムでは、これがデフォルトのランレベルであり、利用可能な場合はグラフィカル ログインが含まれます。 Red-Hat ベースのシステムでは、これはネットワークなしのマルチユーザー モードです。
- 3
Red-Hat ベースのシステムでは、これがデフォルトのマルチユーザー モードであり、グラフィカル環境を除くすべてを実行します。このランレベルとレベル 4 および 5 は、通常、Debian ベースのシステムでは使用されません。
- 4
通常はデフォルトでは使用されないため、カスタマイズが可能です。
- 5
Red-Hat ベースのシステムでは、GUI ログインを使用した完全なマルチユーザー モード。このランレベルはレベル 3 に似ていますが、GUI ログインが利用可能です。
- 6
システムを再起動します。
ランレベルを切り替えるには、init コマンド init N (N は上記のランレベルのいずれか) を使用してランレベルの変更を発行するだけです。これは、実行中のシステムを別のランレベルに移行する推奨方法ではないことに注意してください。この方法では、既存のログイン ユーザーに警告が表示されないため (そのため、ユーザーは作業を失い、プロセスが異常終了する可能性があります)。
代わりに、shutdown コマンドを使用してシステムを再起動する必要があります (最初に、ログインしているすべてのユーザーに警告メッセージが送信され、それ以降のログインがブロックされます。その後、init にランレベルを切り替えるよう信号が送信されます)。ただし、デフォルトのランレベル (システムが起動するランレベル) を最初に /etc/inittab ファイルで編集する必要があります。
そのため、ランレベルを適切に切り替えるには、次の手順に従ってください。root として、/etc/inittab で次の行を探してください。
id:2:initdefault:
vim などのテキスト エディターを使用して、目的のランレベルの番号 2 を変更します (Linux で vi/vim エディターを使用する方法 – このシリーズのパート 2 で説明)。
次に、root として実行します。
# shutdown -r now
その最後のコマンドはシステムを再起動し、次回の起動時に指定されたランレベルで起動し、/etc/rc[runlevel].d にあるスクリプトを実行します。 > ディレクトリを参照して、どのサービスを開始する必要があり、どのサービスを開始しないかを決定します。たとえば、次のシステムのランレベル 2 の場合です。
chkconfigを使用してサービスを管理する
起動時にシステム サービスを有効または無効にするには、CentOS/openSUSE では chkconfig コマンドを、Debian および派生製品では sysv-rc-conf を使用します。このツールは、特定のランレベルのサービスの事前構成された状態を表示することもできます。
こちらもお読みください: Linux で不要なサービスを停止および無効にする方法
サービスのランレベル構成をリストします。
# chkconfig --list [service name]
chkconfig --list postfix
chkconfig --list mysqld
上の画像では、postfix はシステムがランレベル 2 から 5 に入ったときに開始するように設定されているのに対し、 mysqld が確認できます。 b> はデフォルトでランレベル 2 ~ 4 で実行されます。ここで、これが予期された動作ではなかったと仮定します。
たとえば、ランレベル 5 に対しても mysqld をオンにし、ランレベル 4 と 5 に対して postfix をオフにする必要があります。それぞれのケースで行うことは次のとおりです ( root として次のコマンドを実行します)。
特定のランレベルのサービスを有効にする
# chkconfig --level [level(s)] service on
chkconfig --level 5 mysqld on
特定のランレベルのサービスを無効にする
# chkconfig --level [level(s)] service off
chkconfig --level 45 postfix off
次に、sysv-rc-conf を使用してDebian ベースのシステムで同様のタスクを実行します。
sysv-rc-conf を使用してサービスを管理する
特定のランレベルでサービスが自動的に開始され、他のランレベルでは開始されないようにサービスを構成します。
1. 次のコマンドを使用して、mdadm が開始するように構成されているランレベルを確認してみましょう。
# ls -l /etc/rc[0-6].d | grep -E 'rc[0-6]|mdadm'
2. sysv-rc-conf を使用して、2 を除くすべてのランレベルで mdadm が起動しないようにします。必要に応じて (スペースバーを使用して) チェックをオンまたはオフにするだけです (矢印キーで上下左右に移動できます)。
# sysv-rc-conf
次に、q を押して終了します。
3. システムを再起動し、ステップ 1 のコマンドを再度実行します。
# ls -l /etc/rc[0-6].d | grep -E 'rc[0-6]|mdadm'
上の画像では、mdadm がランレベル 2 でのみ起動するように設定されていることがわかります。
systemd についてはどうですか?
systemd は、いくつかの主要な Linux ディストリビューションで採用されているもう 1 つのサービスおよびシステム マネージャーです。これは、システム起動時により多くの処理を並行して実行できるようにすることを目的としています (sysvinit とは異なります。sysvinit は、一度に 1 つずつプロセスを開始し、プロセスが別のプロセスに依存しているかどうかを確認し、プロセスが完了するまで待機するため、常に遅くなる傾向があります)デーモンを起動して、より多くのサービスを開始できるようにし、実行中のシステムに対する動的なリソース管理として機能します。
したがって、サービスは、ブート中に明確な理由なしに起動されるのではなく、必要なときに (システム リソースの消費を避けるために) 開始されます。
システム上で実行されているすべてのプロセス (systemd ネイティブ サービスと SysV サービス) のステータスを表示するには、次のコマンドを実行します。
# systemctl
LOAD 列は、ユニット定義 (systemd によって維持されるサービスまたはその他のものを示す UNIT 列を参照) が適切にロードされたかどうかを示します。 列と SUB 列には、そのユニットの現在のステータスが表示されます。
サービスの現在のステータスに関する情報の表示
アクティブ 列にユニットのステータスがアクティブ以外であることが示されている場合は、を使用して何が起こったのかを確認できます。
# systemctl status [unit]
たとえば、上の画像では、media-samba.mount が失敗した状態になっています。走りましょう。
# systemctl status media-samba.mount
ホスト dev1 上のマウント プロセスが //192.168.0.10/gacanepa< でネットワーク共有を見つけることができなかったため、media-samba.mount が失敗したことがわかります。。
サービスの開始または停止
ネットワーク共有 //192.168.0.10/gacanepa が利用可能になったら、ユニット media-samba.mount を開始し、次に停止し、最後に再起動してみます。各アクションを実行した後、systemctl status media-samba.mount を実行してステータスを確認しましょう。
# systemctl start media-samba.mount
systemctl status media-samba.mount
systemctl stop media-samba.mount
systemctl restart media-samba.mount
systemctl status media-samba.mount
起動時のサービス開始の有効化または無効化
systemd では、サービスの起動時にサービスを有効または無効にできます。
# systemctl enable [service] # enable a service
systemctl disable [service] # prevent a service from starting at boot
起動時にサービスが自動的に開始されるように有効または無効にするプロセスは、/etc/systemd/system/multi-user.target.wants ディレクトリ内のシンボリック リンクを追加または削除することで構成されます。
あるいは、コマンドを使用してサービスの現在のステータス (有効または無効) を確認することもできます。
# systemctl is-enabled [service]
例えば、
# systemctl is-enabled postfix.service
さらに、システムを再起動またはシャットダウンすることもできます。
# systemctl reboot
systemctl shutdown
成り上がり者
Upstart は、/sbin/init デーモンのイベントベースの置き換えであり、必要なときにのみサービスを開始する (サービスの実行中にサービスを監視する) 必要性から生まれました。が実行されている)、イベントが発生したときに処理するため、従来の依存関係ベースの sysvinit システムを超えています。
元々は Ubuntu ディストリビューション用に開発されましたが、Red Hat Enterprise Linux 6.0 で使用されています。これは、sysvinit の代替としてすべての Linux ディストリビューションでの展開に適していることを目的としていましたが、やがて systemd の影に隠れてしまいました。 2014 年 2 月 14 日、Mark Shuttleworth (Canonical Ltd. の創設者) は、Ubuntu の将来のリリースではデフォルトの init デーモンとして systemd を使用することを発表しました。
システムのSysV 起動スクリプトは長い間非常に一般的であるため、多数のソフトウェア パッケージに SysV 起動スクリプトが含まれています。このようなパッケージに対応するために、Upstart は互換モードを提供します。通常の場所 (/etc/rc.d/rc?.d、/etc/init.d/) で SysV 起動スクリプトを実行します。 rc?.d、/etc/rc?.d、または同様の場所)。したがって、Upstart 構成スクリプトがまだ含まれていないパッケージをインストールした場合でも、通常の方法で起動する必要があります。
さらに、chkconfig などのユーティリティをインストールしている場合は、sysvinit ベースのシステムの場合と同じように、それらを使用して SysV ベースのサービスを管理できるはずです。
Upstart スクリプトは、SysV 起動スクリプトよりもさまざまなアクションに基づいたサービスの開始または停止もサポートします。たとえば、Upstart は、特定のハードウェア デバイスが接続されるたびにサービスを起動できます。
Upstart とそのネイティブ スクリプトを使用するシステムは、/etc/inittab ファイルとランレベル固有の SysV 起動スクリプト ディレクトリを .conf に独占的に置き換えます。スクリプトは /etc/init ディレクトリにあります。
これらの *.conf スクリプト (ジョブ定義とも呼ばれます) は通常、次の内容で構成されます。
- プロセスの説明。
- プロセスを実行するランレベル、またはプロセスをトリガーするイベント。
- プロセスを停止する必要があるランレベル、またはプロセスを停止する必要があるイベント。
- オプション。
- プロセスを起動するコマンド。
例えば、
# My test service - Upstart script demo description "Here goes the description of 'My test service'" author "Dave Null <[email >"
Stanzas
#
Stanzas define when and how a process is started and stopped
See a list of stanzas here: http://upstart.ubuntu.com/wiki/Stanzas#respawn
When to start the service
start on runlevel [2345]
When to stop the service
stop on runlevel [016]
Automatically restart process in case of crash
respawn
Specify working directory
chdir /home/dave/myfiles
Specify the process/command (add arguments if needed) to run
exec bash backup.sh arg1 arg2
変更を適用するには、upstart に設定を再ロードするように指示する必要があります。
# initctl reload-configuration
次に、次のコマンドを入力してジョブを開始します。
$ sudo start yourjobname
ここで、yourjobname は、以前に yourjobname.conf スクリプトを使用して追加したジョブの名前です。
Upstart のより完全で詳細なリファレンス ガイドは、プロジェクトの Web サイトのメニュー「Cookbook」から入手できます。
まとめ
Linux ブート プロセスの知識は、タスクのトラブルシューティングを行うだけでなく、コンピューターのパフォーマンスをニーズに合わせて調整したり、サービスを実行したりするためにも必要です。
この記事では、電源 スイッチを押してマシンの電源を入れた瞬間から、完全に操作可能なユーザー インターフェイスが得られるまでに何が起こるかを分析しました。私がこの記事を組み立てたときと同じように、あなたもこの記事を読んで学んでいただければ幸いです。以下にお気軽にコメントやご質問を残してください。読者からのご連絡をいつも楽しみにしています。