この記事は、 systemdの兵器庫のツールボックスを読者に紹介することを目的としています。
シンプルなテキストファイルと多数のスクリプトを備えた旧約聖書システムVの中心にある原則からsystemdが脱却してようやく納得すると、新しい初期化システムとそれに付属するツールの紛れもない利点に気づき始めます。 この記事では、そのうちの4つについて説明し、既にご存知かもしれませんが、ここで説明する方法で使用する可能性の低い別の1つについても説明します。
それでは始めましょう！
coredumpctl
このツールは、便利にその名前を示唆しており、 systemdログからメモリダンプを取得するために使用されます。
coredumpctlコマンドは、すべてのメモリダンプの一般的なリストを返しcoredumpctl 。このリストには、システムの数週間、または数か月間のレコードが含まれることがあります。
図 1. coredumpctlは、ログに記録されたすべてのメモリダンプをリストします
coredumpctl dump filterと、フィルターに適した最後のダンプに関する詳細情報を取得できます。
coredumpctl dump 1758
このコマンドは、PID 1758の最後のダンプの詳細をすべて表示します。また、systemdログは複数のセッション（たとえば、5月に開始）をカバーするため、同じPIDのプロセスからの接続されていないダンプがいくつか含まれる場合があります。
図 2. ダンプ修飾子を使用すると、メモリダンプに関するより詳細な情報を取得できます。
実行可能ファイルの名前でフィルターを設定することもできます。
coredumpctl dump chrome
PIDの場合と同様、このコマンドは最後のダンプに関する情報のみを表示します。ほとんどの場合、それが必要なのは彼だからです。
メモリダンプフィルターは、PID、実行可能ファイルの名前、少なくとも1つのスラッシュを含む必要があるパス（たとえば、 / usr / bin / name_of_executable ）、および1つ以上の一般的な述語journalctlを使用できます。 最後のオプションを次の例に示します。
coredumpctl dump _PID=1758
このコマンドは、本質的にcoredumpctl dump 1758と同じです。 タイムスタンプに関心のあるjournalctl述語を使用したより興味深い例は次のとおりです。
coredumpctl dump _SOURCE_REALTIME_TIMESTAMP=1463932674907840
journalctlの述語リストは、 man systemd.directivesドキュメントファイルのJOURNAL FIELDSセクションにあります。
dumpに加えて、 coredumpctlには他のオプションがあります。 すぐにデバッグを開始したい場合、次のコマンドはすべてのダンプ情報を表示するだけでなく、GNUデバッガー（gdb）を開きます。
coredumpctl gdb 1758
bootctl
ブートはGRUBではなくsystemd-bootによって制御されることをご存知ですか？ はい、これはそれ自体でくしゃくしゃになった別の機能であり、もはやsystemdを停止できないようです。 確かに、これはUEFIを備えたシステムにのみ適用されます。
ブートローダーの設定方法の学習はこの記事の範囲を超えています（本当に興味がある場合は、 ここで有用な情報を見つけることができます）が、カスタムブート設定をセットアップするには、少なくとも基本的なbootctlの知識が必要です 。
（Linuxを初めて使用する場合は、心配しないでください。このセクションで説明することはほとんどありません。ディストリビューションがこれを処理します。ここに書かれていることはすべて、主に絶対制御の愛好家（たとえば、ArchユーザーLinux）。これらの人々は、システムに少なくとも1つのパラメーターが残っていて、微調整を試みていない間は平和に眠ることができません。）
bootctlを使用するには、スーパーユーザー権限が必要なので、このツールを尊重する必要があります。 1つの不注意な動き-そして、システムはロードを停止します。
最も無害なbootctlモードの1つは、ブートステータスのチェックです。 / bootがFAT EFIパーティションを直接ポイントしていない場合、 -path =オプションを使用してEFIブートパーティションへのパスを手動で指定する必要があります。 これは、私のopenSUSEのコマンドのようです。
bootctl --path=/boot/efi
結果は、すべてのブートオプションとそれに対応する変数のリストになります。 図3は、システムでのコマンドの出力を示しています。 これがデフォルトの動作です。 コマンドのフルバージョンは、 bootctl --path=/boot/efi status 。
図 3. bootctlツールを使用すると、ブートマネージャーの設定を表示および変更できます 。
コマンド出力で、ブートオプションとブートローダーバイナリ（ESP）ファイルの場所を確認できます。
変更されたブート構成は、次のコマンドを使用して設定されます。
bootctl --path=/boot/path/to/efi install
このコマンドは、 systemd-bootバイナリファイルも生成し、 boot / path / to / efi / EFI / Bootに保存し、適切な呼び出しをブート優先順位リストの先頭に追加します。
systemd-bootを更新するには、次のようにします。
bootctl --path=/boot/path/to/efi update
EFIパーティションからsystemd-bootを削除するには、次を使用します。
bootctl --path=/boot/path/to/efi remove
最後のコマンドに注意してください。
systemd-cgtop、systemctl、systemd-cgls
従来のtopを使用すると、他のCPUよりもCPUを集中的に使用し 、より多くのメモリを消費するプロセスを見つけることができる場合、 systemd-cgtopはcgroupに対して同じことを行います。
Cgroupsは、システムリソースを分割および分離して、ユーザーおよびタスクのグループに提供するメカニズムです。 たとえば、 cgroupsを使用して、2つのユーザーグループが機能するシステムでメモリとCPU消費の制限を設定できます。 例付きのcgroupの完全な説明は、 ここにあります 。
systemdはcgroupを使用してサービスを制御し、 systemd-cgtopを使用すると、すべてのグループが適切に動作することを確認できます 。 それでも誰かがとんでもないことを始めた場合、グループ全体の作業を一度に一気に完了することができ、各プロセスを個別に検索して停止することはできません。
通常動作するシステムの例を示す図4をご覧ください。 誰もリソースを乱用しておらず、システムのすべてのグループのアクティビティの一般的な指標のみが、結果に沿って数字で示されています。 この場合、たとえばauditdが不適切に振る舞えば 、私はそれを取り除くことができます。 そして、システムはこのサービスなしでは停止しないので、私はそうします：
systemctl kill auditd.service
そして...タダム！ 彼はもういません！
図 4 systemd-cgtopがcgroupの動作を報告します
この場合、 audited.serviceには2つのタスクが関連付けられていましたが、特にエンドユーザーが使用するグループの場合、 それらのタスクは数百になる可能性があるため、 systemctlは cgroupsの操作に非常に便利です。
ところで、どのプロセスが特定のcgroupに関連付けられているかを確認するには、コマンドsystemd-cgls /cgroup.name試してください
例：
systemd-cgls /system.slice/NetworkManager.service
また、NetworkManagerサブグループで動作するすべてのプロセスが表示されます。
おわりに
システム管理を目的としたsystemdツールのごく一部のみを調査しました。 もちろん、もっとたくさんあります。次の記事では、さらにいくつかについて説明します。 また、多くのツールの真の力が多くのオプションに隠されていることを覚えておく価値があります。
systemdに関連する問題をよりよく理解したい場合は、キットに付属のドキュメントから始めることをお勧めします。
man systemd.index
クリエイティブコモンズゼロ