システム管理者が知っているように、最近のコンピューターでは多くのことが起こっています。アプリケーションはバックグラウンドで実行され、自動化されたイベントは特定の時間にトリガーされるのを待ち、ログファイルが書き込まれ、ステータスレポートが配信されます。従来、これらの異なるプロセスは、Unixツールのコレクションを使用して管理および監視され、非常に効果的かつ効率的に機能していました。ただし、最近のコンピューターは多様であり、コンテナー化されたアプリケーションと一緒に実行されるローカルサービス、クラウドとそれらが実行されるクラスターへの簡単なアクセス、リアルタイムプロセス、およびこれまで以上に処理するデータがあります。
それらを管理する統一された方法を持つことは、ユーザーにとっての期待であり、忙しいシステム管理者にとっては便利な贅沢です。この重要なタスクの場合、システムデーモン、または systemd 、開発され、すべての主要なLinuxディストリビューションですぐに採用されました。
システム管理者の詳細
- Sysadminブログを有効にする
- 自動化されたエンタープライズ：自動化によってITを管理するためのガイド
- eBook：システム管理者向けのAnsible自動化
- 現場からの物語：IT自動化に関するシステム管理者ガイド
- eBook：SREおよびシステム管理者向けのKubernetesのガイド
- 最新のシステム管理者の記事
もちろん、Linuxシステムを管理する方法はsystemdだけではありません。 sysvinit、OpenRC、runit、s6、さらにはBusyBoxを含む多くの代替initシステムがありますが、systemdはLinuxを統合データセットとして扱い、堅牢なツールで一貫して操作および照会することを目的としています。忙しいシステム管理者や多くのユーザーにとって、systemdの速度と使いやすさは重要な機能です。これが5つの理由です。
Linuxコンピュータの起動は、必要に応じて、驚くほどまれなイベントになる可能性があります。確かにサーバーの世界では、稼働時間は多くの場合年でカウントされます。 数ヶ月や数週間ではなく。ラップトップとデスクトップは、かなり頻繁にシャットダウンおよび起動される傾向がありますが、これらでさえ、シャットダウンされるのと同じくらい中断または休止状態になる可能性があります。いずれにせよ、最新のブートイベントからの時間は、コンピューターのヘルスチェックの一種のセッションマネージャーとして機能します。これは、システムを監視したり問題を診断したりするときに表示するデータを制限するための便利な方法です。
コンピュータを最後に起動したときのことを思い出せない可能性がある場合は、systemdのログツールであるjournalctlを使用して起動セッションを一覧表示できます。 ：
$ journalctl --list-boots
-42 7fe7c3... Fri 2020-12-04 05:13:59 - Wed 2020-12-16 16:01:23
-41 332e99... Wed 2020-12-16 20:07:39 - Fri 2020-12-18 22:08:13
[...]
-1 e0fe5f... Mon 2021-03-29 20:47:46 - Mon 2021-03-29 21:59:29
0 37fbe4... Tue 2021-03-30 04:46:13 - Tue 2021-03-30 10:42:08
最新のブートセッションがリストの下部に表示されるため、出力をtailにパイプできます。 最新のブーツだけです。
左側の番号（この例では42、41、1、および0）は、各ブートセッションのインデックス番号です。つまり、特定のブートセッションのみのログを表示するには、そのインデックス番号を参照として使用できます。
ログを確認することは、システムに関する情報を推定するための重要な方法です。ログは、直接の監督なしにコンピュータが行ったアクティビティの多くの履歴を提供します。サービスがいつ開始されたか、時間指定されたジョブがいつ実行されたか、どのサービスがバックグラウンドで実行されているか、どのアクティビティが失敗したかなどを確認できます。最も一般的な最初のトラブルシューティング手順の1つは、ログを確認することです。これは、journalctlで簡単に実行できます。 ：
$ journalctl --pager-end
--pager-end （または-e 略して）オプションは、journalctlの最後にログの表示を開始します 出力されるため、上にスクロールして以前に発生したイベントを確認する必要があります。
Systemdは、エラーの「カタログ」と、エラーの記録、考えられる解決策、サポートフォーラムへのポインター、および開発者向けドキュメントで満たされたメッセージを保持しています。これは、ログイベントに重要なコンテキストを提供する可能性があります。そうしないと、メッセージの海で混乱を招く可能性があり、さらに悪いことに、完全に見過ごされる可能性があります。エラーメッセージを説明テキストと統合するには、--catalogを使用できます。 （または-x 略して）オプション：
$ journalctl --pager-end --catalog
ウェイドスルーする必要のあるログ出力をさらに制限するために、ログを表示するブートセッションを指定できます。各ブートセッションにはインデックスが付けられているため、--bootを使用して特定のセッションを指定できます。 オプションを選択し、それに適用されるログのみを表示します：
$ journalctl --pager-end --catalog --boot 42
特定のsystemdユニットのログも表示できます。たとえば、セキュアシェル（SSH）サービスの問題をトラブルシューティングするには、--unit sshdを指定できます。 sshdに適用されるログのみを表示します デーモン：
$ journalctl --pager-end \
--catalog --boot 42 \
--unit sshd
systemdの最初のタスクはコンピューターを起動することであり、通常はそれを迅速、効率的、効果的に実行します。しかし、決して終わらないタスクはサービス管理です。設計上、systemdは、実行するサービスが実際に開始され、セッション中に実行を継続することを保証します。理論的には、クラッシュしたサービスでもユーザーの介入なしに再起動できるため、これは非常に堅牢です。
systemdがサービスを管理するのに役立つインターフェースはsystemctlです。 指図。これを使用すると、サービスを定義するユニットファイルを表示できます。
$ systemctl cat sshd
# /usr/lib/systemd/system/sshd.service
[Unit]
Description=OpenSSH server daemon
Documentation=man:sshd(8) man:sshd_config(5)
After=network.target sshd-keygen.target
Wants=sshd-keygen.target
[Service]
Type=notify
EnvironmentFile=-/etc/crypto-policies/back-ends/opensshserver.config
EnvironmentFile=-/etc/sysconfig/sshd
ExecStart=/usr/sbin/sshd -D $OPTIONS $CRYPTO_POLICY
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartSec=42s
[Install]
WantedBy=multi-user.target
ほとんどのユニットファイルは/usr/lib/systemd/system/にあります ただし、多くの重要な構成と同様に、ローカルの変更でそれらを変更することをお勧めします。そのためのインターフェースもあります：
$ systemctl edit sshdサービスが現在アクティブであるかどうかを確認できます：
$ systemctl is-active sshd
active
$ systemctl is-active foo
inactive
同様に、サービスがis-failedで失敗したかどうかを確認できます 。
サービスの開始と停止は非常に直感的です：
$ systemctl stop sshd
$ systemctl start sshd
また、起動時にサービスを開始できるようにするのは簡単です。
$ systemctl enable sshd
--nowを追加します 起動時にサービスを開始できるようにするオプション、または現在のセッションでサービスを開始できるようにするオプション。
ずっと前に、Linuxでタスクを自動化したいと思ったとき、そのジョブの標準的なツールはcronでした。 。 cronコマンドの場所はまだありますが、いくつかの説得力のある代替手段もあります。たとえば、anacron コマンドは、ダウンタイム中に見逃されていたであろうタスクを実行できる、用途の広いcronのようなシステムです。
スケジュールされたイベントは、特定の時間にアクティブ化されるサービスにすぎないため、systemdはタイマーと呼ばれるcronのような機能を管理します。アクティブなタイマーを一覧表示できます：
$ systemctl list-timers
NEXT LEFT
Tue 2021-03-30 12:37:54 NZDT 16min left [...]
Wed 2021-03-31 00:00:00 NZDT 11h left [...]
Wed 2021-03-31 06:42:02 NZDT 18h left [...]
3 timers listed.
Pass --all to see loaded but inactive timers, too.
サービスを有効にするのと同じ方法でタイマーを有効にできます：
$ systemctl enable myMonitor.timer
ターゲットは、systemdマトリックスの最後の主要コンポーネントです。ターゲットは、サービスやタイマーと同じように、ユニットファイルによって定義されます。ターゲットも同じ方法で開始および有効化できます。ターゲットをユニークにするのは、他のユニットファイルを任意に重要な方法でグループ化することです。たとえば、グラフィカルデスクトップではなくテキストコンソールで起動したい場合は、multi-user ターゲットが存在します。ただし、multi-user ターゲットはgraphicalのみです 依存関係としてデスクトップユニットファイルを使用しないターゲット。
つまり、ターゲットは、サービス、タイマー、さらには他のターゲットをまとめて収集し、マシンの意図された状態を表すための簡単な方法です。
実際、systemd内では、再起動、電源オフ、またはシャットダウンアクションは単なる別のターゲットです。
list-unit-filesを使用して、使用可能なすべてのターゲットを一覧表示できます オプション、--typeで制約します オプションをtargetに設定 ：
$ systemctl list-unit-files --type target最新のLinuxは、サービス管理とログのイントロスペクションにsystemdを使用しています。パーソナルLinuxシステムからエンタープライズサーバーまで、監視と簡単なメンテナンスのための最新のメカニズムを備えています。使用すればするほど、systemdは快適に予測可能で直感的になり、システムのさまざまな部分がどのように相互接続されているかがわかります。
systemdに精通するには、systemdを使用する必要があります。また、使い慣れるために、チートシートをダウンロードして、頻繁に参照してください。