LFCS:システム起動プロセスとサービスの管理(SysVinit、Systemd、Upstart)-パート7


数か月前、Linux FoundationはLFCS(Linux Foundation Certified Sysadmin)認定を発表しました。これは、世界中の個人がLinuxシステムで基本から中級のシステム管理タスクを実行する認定を取得できるようにすることを目的としたエキサイティングな新しいプログラムです。これには、すでに実行されているシステムとサービスのサポート、直接の問題発見と分析、およびエンジニアリングチームに問題を提起する時期を決定する機能が含まれます。

次のビデオでは、LinuxFoundation認定プログラムの簡単な紹介について説明しています。

この投稿は、10チュートリアルシリーズのパート7です。このパートでは、LFCS認定試験に必要なLinuxシステムの起動プロセスとサービスを管理する方法について説明します。

Linux起動プロセスの管理

Linuxシステムのブートプロセスはいくつかのフェーズで構成され、各フェーズは異なるコンポーネントで表されます。次の図は、起動プロセスを簡単に要約し、関連するすべての主要コンポーネントを示しています。

マシンの電源ボタンを押すと、マザーボードの EEPROM チップに保存されているファームウェアが POST )を初期化します。 Power-On Self Test )を使用して、システムのハードウェアリソースの状態を確認します。 POST が終了すると、ファームウェアは MBR または EFIにある第1ステージブートローダーを検索してロードします。 最初に使用可能なディスクのパーティションであり、それを制御します。

MBR は、 BIOS 設定で起動可能としてマークされたディスクの最初のセクターにあり、サイズは 512 バイトです。

  1. First 446 bytes: The bootloader contains both executable code and error message text.
  2. Next 64 bytes: The Partition table contains a record for each of four partitions (primary or extended). Among other things, each record indicates the status (active / not active), size, and start / end sectors of each partition.
  3. Last 2 bytes: The magic number serves as a validation check of the MBR.

次のコマンドは、 MBR のバックアップを実行します(この例では、/dev/sda が最初のハードディスクです)。結果のファイル mbr.bkp は、パーティションテーブルが破損した場合、たとえばシステムが起動できなくなった場合に役立ちます。

もちろん、後で必要になったときに使用するには、保存して別の場所( USB ドライブなど)に保存する必要があります。そのファイルは、MBRを復元するのに役立ち、その間にハードドライブのレイアウトを変更しない場合にのみ、もう一度実行できます。

# dd if=/dev/sda of=mbr.bkp bs=512 count=1
# dd if=mbr.bkp of=/dev/sda bs=512 count=1

EFI / UEFI 方式を使用するシステムの場合、UEFIファームウェアはその設定を読み取り、どのUEFIアプリケーションをどこから起動するか(つまり、どのディスクとパーティションでEFIパーティションがあります)。

次に、第2段階のブートローダー(別名ブートマネージャー)が読み込まれ、実行されます。 GRUB [ GRand Unified Boot ]は、Linuxで最も頻繁に使用されるブートマネージャーです。現在使用されているほとんどのシステムには、2つの異なるバージョンのいずれかがあります。

  1. GRUB legacy configuration file: /boot/grub/menu.lst (older distributions, not supported by EFI/UEFI firmwares).
  2. GRUB2 configuration file: most likely, /etc/default/grub.

LFCS 試験の目的は、 GRUB の内部に関する知識を明示的に要求するものではありませんが、勇気があり、システムを台無しにする余裕がある場合は(試してみることをお勧めします)念のため、最初に仮想マシンで実行する必要があります。

# update-grub

変更を適用するためにGRUBの構成を変更した後、 root として。

基本的に、 GRUB はデフォルトの kernel initrd または initramfs イメージをロードします。簡単に言うと、initrdまたはinitramfsは、実際のルートファイルシステムをマウントするために必要なハードウェア検出、カーネルモジュールのロード、およびデバイス検出の実行に役立ちます。

実際のルートファイルシステムが起動すると、カーネルはシステムとサービスマネージャー( init または systemd 、プロセスIDまたはPIDは常に1)を実行して、通常のユーザーを開始します-ユーザーインターフェイスを表示するためのスペースブートプロセス。

init systemd はどちらも、他のデーモンを管理するデーモン(バックグラウンドプロセス)であり、最初に開始するサービス(ブート中)と最後に終了するサービス(シャットダウン中)として機能します。

サービスの開始(SysVinit)

Linuxのランレベルの概念は、実行中のサービスを制御することにより、システムを使用するさまざまな方法を指定します。言い換えると、ランレベルは、現在の実行状態u003dランレベルで実行できるタスク(および実行できないタスク)を制御します。

従来、この起動プロセスは、 System V UNIX で始まった規則に基づいて実行されていました。システムは、マシンが特定のランレベルに入るとサービスを開始および停止するスクリプトの実行コレクションを渡します(つまり、 、はシステムを実行する別のモードです)。

各ランレベル内で、個々のサービスを実行するように設定することも、実行中の場合はシャットダウンするように設定することもできます。一部の主要なディストリビューションの最新バージョンは、 System V 標準から移行し、 systemd (システムデーモンの略)と呼ばれるかなり新しいサービスおよびシステムマネージャーを採用していますが、通常は互換性のために sysv コマンドをサポートします。これは、有名な sysv initツールのほとんどをsystemdベースのディストリビューションで実行できることを意味します。

関連項目:Linuxで「systemd」が「init」に置き換わる理由

init は、システムプロセスの開始に加えて、/etc/inittab ファイルを参照して、入力する必要のあるランレベルを決定します。

ランレベルを切り替えるには、 init コマンドを使用してランレベルの変更を発行します。init N (Nは上記のランレベルの1つです)。これは、既存のログインユーザーに警告を表示しないため、実行中のシステムを別のランレベルに移動するための推奨される方法ではないことに注意してください(したがって、ユーザーは作業を失い、プロセスは異常終了します)。

代わりに、 shutdown コマンドを使用してシステムを再起動する必要があります(最初にすべてのログインユーザーに警告メッセージを送信し、それ以降のログインをブロックします。次に、ランレベルを切り替えるようにinitに通知します)。ただし、デフォルトのランレベル(システムが起動するレベル)は、最初に/etc/inittab ファイルで編集する必要があります。

そのため、次の手順に従ってランレベルを適切に切り替えます。rootとして、/etc/inittab で次の行を探します。

id:2:initdefault:

そして、vimなどの好みのテキストエディターで目的のランレベルの数値 2 を変更します(Linuxでvi/vimエディターを使用する方法–このシリーズのパート2で説明されています)。

次に、rootとして実行します。

# shutdown -r now

その last コマンドはシステムを再起動し、次回の起動時に指定されたランレベルでシステムを起動し、 /etc/rc[runlevel].d どのサービスを開始し、どのサービスを開始しないかを決定するためのディレクトリ。たとえば、次のシステムのランレベル2の場合。

起動時にシステムサービスを有効または無効にするには、CentOS/openSUSEではchkconfigコマンドを使用し、Debianおよび派生物では sysv-rc-conf を使用します。このツールは、特定のランレベルのサービスの事前構成された状態を表示することもできます。

関連項目:Linuxで不要なサービスを停止および無効にする方法

サービスのランレベル構成を一覧表示します。

# chkconfig --list [service name]
# chkconfig --list postfix
# chkconfig --list mysqld

上の画像では、システムがランレベル 2 から 5 に入ると、 postfix が開始するように設定されているのに対し、 mysqld は、ランレベル 2 から 4 でデフォルトで実行されます。ここで、これが予期された動作ではないとします。

たとえば、ランレベル 5 でも mysqld をオンにし、ランレベル4と5では接尾辞をオフにする必要があります。ルートとして次のコマンド)。

# 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ベースシステムで同様のタスクを実行します。

特定のランレベルで自動的に開始し、他のすべてのランレベルで開始されないようにサービスを構成します。

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 は、一度に1つずつ処理を開始し、依存しているかどうかを確認し、待機するため、常に遅くなる傾向があります。より多くのサービスを開始できるように起動するデーモン)、および実行中のシステムへの動的なリソース管理として機能します。

したがって、サービスは、起動時に確固たる理由なしに起動されるのではなく、必要なときに(システムリソースの消費を避けるために)開始されます。

systemd ネイティブサービスと SysV サービスの両方で、システムで実行されているすべてのプロセスのステータスを表示するには、次のコマンドを実行します。

# systemctl

LOAD 列は、 ACTIVE 列と SUB 列は、そのようなユニットの現在のステータスを示します。

ACTIVE 列にユニットのステータスがアクティブ以外であることが示されている場合は、を使用して何が起こったかを確認できます。

# systemctl status [unit]

たとえば、上の画像では、 media-samba.mount は失敗状態にあります。走りましょう。

# systemctl status media-samba.mount

ホスト dev1 のマウントプロセスが/192.168.0.10/gacanepa <でネットワーク共有を見つけることができなかったため、 media-samba.mount が失敗したことがわかります。/b>。

サービスの開始または停止

ネットワーク共有/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 Linux6.0で使用されています。 sysvinit の代わりとして、すべてのLinuxディストリビューションでの展開に適していることを目的としていましたが、やがて systemd によって影が薄くなりました。 2014年2月14日、Mark Shuttleworth(Canonical Ltd.の創設者)は、Ubuntuの将来のリリースでsystemdをデフォルトのinitデーモンとして使用することを発表しました。

システムの SysV 起動スクリプトは非常に長い間一般的であったため、多数のソフトウェアパッケージにSysV起動スクリプトが含まれています。このようなパッケージに対応するために、Upstartは互換モードを提供します。通常の場所( /etc/rc.d/rc?.d /etc/init.d/)でSysV起動スクリプトを実行します。 rc?.d /etc/rc?.d 、または同様の場所)。したがって、Upstart構成スクリプトがまだ含まれていないパッケージをインストールした場合でも、通常の方法で起動するはずです。

さらに、chkconfigなどのユーティリティをインストールしている場合は、sysvinitベースのシステムの場合と同じように、それらを使用してSysVベースのサービスを管理できるはずです。

アップスタートスクリプトは、SysVスタートアップスクリプトよりもさまざまなアクションに基づいてサービスを開始または停止することもサポートしています。たとえば、Upstartは、特定のハードウェアデバイスが接続されているときはいつでもサービスを起動できます。

Upstartとそのネイティブスクリプトを使用するシステムは、/etc/inittab ファイルとランレベル固有の SysV 起動スクリプトディレクトリを .conf に排他的に置き換えます。 /etc/init ディレクトリ内のスクリプト。

これらの *。conf スクリプト(ジョブ定義とも呼ばれます)は、通常、次のもので構成されます。

    1. Description of the process.
    2. Runlevels where the process should run or events that should trigger it.
    3. Runlevels where process should be stopped or events that should stop it.
    4. Options.
    5. Command to launch the process.

    例えば、

    # My test service - Upstart script demo description "Here goes the description of 'My test service'" author "Dave Null <[email protected]>"
    # 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サイトの[クックブック]メニューから入手できます。

    概要

    Linuxブートプロセスの知識は、タスクのトラブルシューティング、およびコンピューターのパフォーマンスの適応とニーズへのサービスの実行を支援するために必要です。

    この記事では、電源スイッチを押してマシンの電源を入れてから、完全に機能するユーザーインターフェイスが表示されるまでに何が起こるかを分析しました。まとめながら読んだのと同じくらい読んでいただければ幸いです。以下にコメントや質問を残してください。読者の皆様からのご意見をお待ちしております!

全著作権所有。 © Linux-Console.net • 2019-2022