このシリーズの最初の2つの記事では、Linuxのsystemdの起動シーケンスについて説明しました。最初の記事では、systemdの機能とアーキテクチャ、および古いSystemVinitプログラムと起動スクリプトの代わりとしてのその役割に関する論争について説明しました。また、2番目の記事では、systemctlとjournalctlという2つの重要なsystemdツールを調べ、あるターゲットから別のターゲットに切り替える方法と、デフォルトのターゲットを変更する方法について説明しました。
この3番目の記事では、systemdユニットの詳細と、systemctlコマンドを使用してユニットを探索および管理する方法について説明します。また、ユニットを停止して無効にする方法と、新しいsystemdマウントユニットを作成して新しいファイルシステムをマウントし、起動時に開始できるようにする方法についても説明します。
システム管理者の詳細
- Sysadminブログを有効にする
- 自動化されたエンタープライズ:自動化によってITを管理するためのガイド
- eBook:システム管理者向けのAnsible自動化
- 現場からの物語:IT自動化に関するシステム管理者ガイド
- eBook:SREおよびシステム管理者向けのKubernetesのガイド
- 最新のシステム管理者の記事
この記事のすべての実験は、rootユーザーとして実行する必要があります(特に指定のない限り)。さまざまなsystemdユニットをリストするだけのコマンドの中には、root以外のユーザーが実行できるものもありますが、変更を加えるコマンドは実行できません。これらの実験はすべて、非実稼働ホストまたは仮想マシン(VM)でのみ実行してください。
これらの実験の1つにはsysstatパッケージが必要なので、先に進む前にインストールしてください。 Fedoraおよびその他のRedHatベースのディストリビューションの場合、次のコマンドを使用してsysstatをインストールできます。
dnf -y install sysstat
sysstat RPMは、問題判別に使用できるいくつかの統計ツールをインストールします。 1つはシステムアクティビティレポート(SAR)で、これは一定の間隔(デフォルトでは10分ごと)で多くのシステムパフォーマンスデータポイントを記録します。 sysstatパッケージは、バックグラウンドでデーモンとして実行するのではなく、2つのsystemdタイマーをインストールします。 1つのタイマーは10分ごとに実行されてデータを収集し、もう1つのタイマーは1日1回実行されて毎日のデータを集約します。この記事では、これらのタイマーについて簡単に説明しますが、今後の記事でタイマーを作成する方法を説明するのを待ちます。
systemdスイート
実際のところ、systemdは単なる1つのプログラムではありません。これは、実行中のLinuxシステムのほぼすべての側面を管理するために連携して動作するように設計されたプログラムの大規模なスイートです。 systemdの完全な説明は、それ自体で本を取ります。私たちのほとんどは、systemdのすべてのコンポーネントがどのように組み合わされているかについての詳細をすべて理解する必要はないので、さまざまなLinuxサービスを管理し、ログファイルやジャーナルを処理できるようにするプログラムとコンポーネントに焦点を当てます。
systemdの構造(実行可能ファイル以外)は、多くの構成ファイルに含まれています。これらのファイルの名前と識別子の拡張子は異なりますが、すべて「ユニット」ファイルと呼ばれます。単位はsystemdのすべての基礎です。
ユニットファイルは、sysadminにアクセスでき、sysadminによって作成または変更できるASCIIプレーンテキストファイルです。ユニットファイルの種類はいくつかあり、それぞれに独自のマニュアルページがあります。図1に、これらのユニットファイルタイプの一部をファイル名拡張子とそれぞれの簡単な説明別に示します。
systemd unit | 説明 |
---|---|
.automount | .automount ユニットは、起動時にオンデマンド(つまり、プラグアンドプレイ)とファイルシステムユニットのマウントを並行して実装するために使用されます。 |
.device | .device ユニットファイルは、 / dev / directoryのsysadminに公開されるハードウェアおよび仮想デバイスを定義します 。すべてのデバイスにユニットファイルがあるわけではありません。通常、ハードドライブ、ネットワークデバイスなどのブロックデバイスには、ユニットファイルがあります。 |
.mount | .mount unitは、Linuxファイルシステムのディレクトリ構造にマウントポイントを定義します。 |
.scope | .scope ユニットは、一連のシステムプロセスを定義および管理します。このユニットは、ユニットファイルを使用して構成されているのではなく、プログラムで作成されています。 systemd.scopeごと マニュアルページ、「スコープユニットの主な目的は、組織化およびリソース管理のためにシステムサービスのワーカープロセスをグループ化することです。」 |
.service | .service ユニットファイルは、systemdによって管理されるプロセスを定義します。これらには、crond cups(Common Unix Printing System)、iptables、複数の論理ボリューム管理(LVM)サービス、NetworkManagerなどのサービスが含まれます。 |
.slice | .slice ユニットは、プロセスのグループに関連するシステムリソースの概念的な分割である「スライス」を定義します。すべてのシステムリソースをパイと見なすことができ、このリソースのサブセットをそのパイからの「スライス」と見なすことができます。 |
.socket | .socket ユニットは、ネットワークソケットなどのプロセス間通信ソケットを定義します。 |
.swap | .swap ユニットはスワップデバイスまたはファイルを定義します。 |
.target | .target ユニットは、起動同期ポイント、ランレベル、およびサービスを定義するユニットファイルのグループを定義します。ターゲットユニットは、正常に開始するためにアクティブである必要があるサービスおよびその他のユニットを定義します。 |
.timer | .timer unitは、指定された時間にプログラムの実行を開始できるタイマーを定義します。 |
systemctl
2番目の記事でsystemdの起動機能について説明しました。ここでは、systemdのサービス管理機能についてもう少し詳しく説明します。 systemdはsystemctlを提供します サービスを開始および停止し、システムの起動時に起動する(または起動しない)ように構成し、実行中のサービスの現在のステータスを監視するために使用されるコマンド。
rootユーザーとしてのターミナルセッションで、rootのホームディレクトリ(〜)を確認します )は障害者です。さまざまな方法でユニットの確認を開始するには、ロードされているアクティブなsystemdユニットをすべてリストします。 systemctlは、stdoutデータストリームを少ないに自動的にパイプします ポケットベルなので、次のことを行う必要はありません。
[root @ testvm1〜]#systemctl
UNIT LOADACTIVESUB実行可能ファイル00-0000:00:01.1-ata7-host6-target6:0:0-6:0:0:0-block-sr0.deviceがロードされました>
sys-devices-pci0000:00-0000:00: 03.0-net-enp0s3.deviceがアクティブに接続されました82540EMGigabi>
sys-devices-pci0000:00-0000:00:05.0-sound-card0.deviceがアクティブに接続されています82801AA AC'97>
sys- devices-pci0000:00-0000:00:08.0-net-enp0s8.deviceがアクティブに接続されました82540EM Gigabi>
sys-devices-pci0000:00-0000:00:0d.0-ata1-host0-target0:0 :0-0:0:0:0-block-sda-sda1.device loa>
sys-devices-pci0000:00-0000:00:0d.0-ata1-host0-target0:0:0- 0:0:0:0-block-sda-sda2.device loa>
LOAD=ユニット定義が適切であったかどうかを反映しますロードされました。
ACTIVE=高レベルのユニットアクティベーション状態、つまりSUBの一般化。
SUB =低レベルのユニットアクティベーション状態、値はユニットタイプによって異なります。
206個のロードされたユニットがリストされています。 --allを渡すと、ロードされているが非アクティブなユニットも表示されます。
インストールされているすべてのユニットファイルを表示するには、「systemctllist-unit-files」を使用します。
ターミナルセッションでデータをスクロールしながら、特定のものを探します。最初のセクションには、ハードドライブ、サウンドカード、ネットワークインターフェイスカード、TTYデバイスなどのデバイスが一覧表示されます。別のセクションには、ファイルシステムのマウントポイントが表示されます。他のセクションには、さまざまなサービスと、ロードされているすべてのアクティブなターゲットのリストが含まれています。
出力の下部にあるsysstatタイマーは、SARの毎日のシステムアクティビティの概要を収集および生成するために使用されます。 SARは非常に便利な問題解決ツールです。 (これについて詳しくは、私の本の第13章 Linuxの使用と管理:第1巻、ゼロからシステム管理者:はじめにを参照してください。 。)
一番下の近くにある3行は、ステータス(ロード済み、アクティブ、サブ)の意味を示しています。 qを押します ポケットベルを終了します。
次のコマンド(上記の出力の最後の行で提案されている)を使用して、ロードされているかどうかに関係なく、インストールされているすべてのユニットを確認します。自分でスクロールできるので、ここでは出力を再現しません。 systemctlプログラムには、すべてのオプションを覚えなくても複雑なコマンドを簡単に入力できる優れたタブ補完機能があります。
[root@testvm1 ~]# systemctl list-unit-files
一部のユニットが無効になっていることがわかります。 systemctlリストのマニュアルページの表1に、このリストに表示される可能性のあるエントリの簡単な説明が記載されています。 -tを使用します (タイプ)タイマーユニットのみを表示するオプション:
[root @ testvm1〜]#systemctl list-unit-files -t timer
UNIT FILE STATE
[email protected] disable
dnf-makecache.timer
dnf-makecache.timer
dnf-makecache.timer
dnf-makecache.timer>fstrim.timer無効
logrotate.timer無効
logwatch.timer無効
mdadm-last-resort @ .timer /> disable
mdadm-last-resort @ .timer collect.timer enabled
sysstat-summary.timer enabled
systemd-tmpfiles-clean.timer static
unbound-anchor.timer enabled
この代替案でも同じことができます。これにより、かなり詳細な情報が得られます。
[root @ testvm1〜]#systemctl list-timers
Thu 2020-04-16 09:06:20 EDT 3min 59s left n / a n / a n / a tmpfiles-clean.timer systemd clean.service
Thu 2020-04-16 10:02:01EDT59分左Thu2020-04-1609:01:32EDT49秒前dnf-makecache.timerdnf-makecache.service
Thu 2020-04-16 13:00:00EDT3時間57分左該当なし該当なしsysstat-collect.timersysstat-collect.service
Fri 2020-04-17 00:00:00 EDT -04-16 12:51:37 EDT 3h 49min left mlocate-updatedb.timer mlocate-updatedb.service
Fri 2020-04-17 00:00:00 EDT 14h left Thu 2020-04-16 12:51 :37 EDT 3h 49min left unbound-anchor.timer unbound-anchor.service
Fri 2020-04-17 00:07:00 EDT 15h left n / a sys mary-sum
6つのタイマーがリストされています。
-allに合格すると、ロードされているが非アクティブなタイマーも表示されます。
[root @ testvm1〜]#
systemctl list-mountsを実行するオプションはありませんが、マウントポイントユニットファイルを一覧表示できます。
[root @ testvm1〜]#systemctl list-unit-files -t mount
UNIT FILE STATE
-.mount生成されたページ生成された
boot .mountマウントstatic
dev-mqueue.mount static
home.mount生成された
proc-fs-nfsd.mount run-vmblock\x2dfuse.mount無効
sys-fs-fuse-connections.mount static
sys-kernel-config.mount static
sys-kernel-debug.mount static
tmp.mount生成された
usr.mount生成された
var-lib-nfs-rpc_pipefs.mountstatic
var.mount
var.mount
リストされた
> [root @ testvm1〜]#
このデータストリームのSTATE列は興味深いものであり、少し説明が必要です。 「生成された」状態は、 / etc / fstab の情報を使用して、起動時にマウントユニットがオンザフライで生成されたことを示します。 。これらのマウントユニットを生成するプログラムは、 / lib / systemd / system-generators / systemd-fstab-generatorです。 他の多くのユニットタイプを生成する他のツールと一緒に。 「静的」マウントユニットは、 / procなどのファイルシステム用です。 および/sys 、およびこれらのファイルは / usr / lib / systemd / systemにあります ディレクトリ。
次に、サービスユニットを見てください。このコマンドは、アクティブであるかどうかに関係なく、ホストにインストールされているすべてのサービスを表示します。
[root@testvm1 ~]# systemctl --all -t service
このサービスユニットのリストの下部には、ホストにロードされたユニットの総数として166が表示されます。あなたの番号はおそらく異なるでしょう。
ユニットファイルにはファイル名拡張子がありません( .unit など) )それらを識別するのに役立つため、systemdに属するほとんどの構成ファイルはあるタイプまたは別のタイプのユニットファイルであると一般化できます。残りのいくつかのファイルは、ほとんどが .confです。 / etc / systemdにあるファイル 。
ユニットファイルは/usr / lib / systemdに保存されます ディレクトリとそのサブディレクトリ、 / etc / systemd / ディレクトリとそのサブディレクトリには、このホストのローカル構成に必要なユニットファイルへのシンボリックリンクが含まれています。
これを調べるには、 / etc / systemdを作成します PWDとその内容を一覧表示します。次に、 / etc / systemd / systemを作成します PWDとその内容を一覧表示し、現在のPWDのサブディレクトリの少なくともいくつかの内容を一覧表示します。
default.targetをご覧ください ファイル。システムが起動するランレベルターゲットを決定します。このシリーズの2番目の記事では、GUI( graphicsal.target )からデフォルトのターゲットを変更する方法について説明しました。 )コマンドラインのみ( multi-user.target ) 目標。 default.target テストVM上のファイルは、/usr/lib/systemd/system/graphical.targetへのシンボリックリンクにすぎません。 。
/etc/systemd/system/default.target の内容を確認するには、数分かかります ファイル:
[root @ testvm1 system]#cat default.target
#SPDX-License-Identifier:LGPL-2.1 +
#
#このファイルはsystemdの一部です。
#
#systemdはフリーソフトウェアです。
#フリーソフトウェアファウンデーションによって公開されているGNU劣等一般公衆利用許諾契約書の条件に基づいて、再配布および/または変更することができます。
#ライセンスのバージョン2.1、または
#(オプションで)以降のバージョン。
[Unit]
Description =Graphical Interface
Documentation =man:systemd .special(7)
Requireds =multi-user.target
Wants =display-manager.service
Conflicts =restcue.servicerescue.target
After =multi-user.targetレスキュー.サービスrescue.targetdisplay-manager.service
AllowIsolate =yes
これにはmulti-user.targetが必要であることに注意してください; graphics.target multi-user.target の場合、開始できません まだ稼働していません。また、 display-manager.serviceが「欲しい」とも書かれています。 単位。ユニットを正常に起動するために、「必要」を満たす必要はありません。 「want」を実行できない場合、systemdはそれを無視し、残りのターゲットは関係なく開始されます。
/ etc / systemd / systemのサブディレクトリ さまざまなターゲットの要望のリストです。 /etc/systemd/system/graphical.target.wants にあるファイルとその内容を調べるには、数分かかります。 ディレクトリ。
systemd.unit マニュアルページには、ユニットファイル、その構造、分割できるセクション、および使用できるオプションに関する多くの優れた情報が含まれています。また、多くのユニットタイプがリストされており、そのすべてに独自のマニュアルページがあります。ユニットファイルを解釈したい場合は、ここから始めるとよいでしょう。
Fedoraのインストールは通常、特定のホストが通常の操作に必要としないサービスをインストールして有効にします。逆に、インストール、有効化、および開始が必要なサービスが含まれていない場合もあります。 Linuxホストが希望どおりに機能するために必要ではないが、インストールされて実行されている可能性のあるサービスは、セキュリティリスクを表すため、少なくとも停止して無効にし、せいぜいアンインストールする必要があります。
systemctlコマンドは、サービス、ターゲット、マウントなどのsystemdユニットを管理するために使用されます。サービスのリストを詳しく調べて、使用されることのないサービスを特定します。
<前> [ルート@ testvm1〜]#systemctl --all -tサービスユニット負荷ACTIVE SUB説明
<スニップ>
chronyd.serviceロードされたアクティブな実行中のNTPクライアント/サーバー
crond.serviceはアクティブ実行中のコマンドスケジューラは
cups.service
DBUS-daemon.serviceがロードスケジューラアクティブランニングカップをロードロードアクティブランニングDバスシステムメッセージバス
<スニップ>
●ip6tables.service非アクティブ見つからない死んだip6tables.service
●ipset.serviceない-た非アクティブ死んipset.service
●iptables.service-見つからない非アクティブ死んiptables.service
<スニップ>
firewalld.serviceロード済みアクティブ実行中firewalld-動的firew ntpdate.service
pcscd.serviceすべてのデーモン
<スニップ>
●ntpd.service-見つからない非アクティブntpd.service
●ntpdate.serviceデッド見つからない非アクティブ死者はアクティブロードPC/SCスマートカードデーモンの実行
スペースを節約するために、コマンドからの出力のほとんどを削除しました。 「ロードされたアクティブな実行中」を示すサービスは明らかです。 「見つからない」サービスとは、systemdが認識しているが、Linuxホストにインストールされていないサービスです。これらのサービスを実行する場合は、それらを含むパッケージをインストールする必要があります。
pcscd.serviceに注意してください 単位。これはPC/SCスマートカードデーモンです。その機能は、スマートカードリーダーと通信することです。多くのLinuxホスト(VMを含む)は、このリーダーも、ロードされてメモリとCPUリソースを消費するサービスも必要ありません。このサービスを停止して無効にすることができるため、次回の起動時に再起動しません。まず、ステータスを確認します:
[root @ testvm1〜]#systemctl status pcscd.service
●pcscd.service-PC/SCスマートカードデーモン
ロード済み:ロード済み(/usr/lib/systemd/system/pcscd.service;間接;ベンダープリセット:無効)
アクティブ:アクティブ(実行中)2019-05-1011:28:42EDT以降; 3日前
ドキュメント:man:pcscd(8)
メインPID:24706(pcscd)
タスク:6(制限:4694)
メモリ:1.6M
CGroup:/system.slice/pcscd.service
└─24706/usr / sbin / pcscd --foreground --auto-exit
May 10 11:28:42 testvm1 systemd [1 ]:PC/SCスマートカードデーモンを開始しました。
このデータは、systemdが提供する追加情報と、サービスが実行されているかどうかのみを報告するSystemVを示しています。 .serviceを指定することに注意してください ユニットタイプはオプションです。次に、サービスを停止して無効にし、ステータスを再確認します。
[root @ testvm1〜]#systemctl stop pcscd; systemctl disable pcscd
警告:pcscd.serviceを停止していますが、次の方法でアクティブ化できます:
pcscd.socket
/etc/systemd/system/sockets.target.wants/pcscd.socketを削除しました。
[root @ testvm1〜]#systemctl status pcscd
●pcscd.service-PC/SCスマートカードデーモン
ロード済み:ロード済み(/usr/lib/systemd/system/pcscd.service;間接;ベンダープリセット:無効)
アクティブ:失敗(結果:終了コード)2019-05-1315:23:15EDT以降; 48秒前
ドキュメント:man:pcscd(8)
メインPID:24706(code =exited、status =1 / FAILURE)
May 10 11:28:42 testvm1 systemd [1]:PC/SCスマートカードデーモンを開始しました。
5月13日15:23:15testvm1systemd [1]:PC/SCスマートカードデーモンを停止しています...
5月13日15:23:15 testvm1 systemd [1]:pcscd.service:メインプロセスが終了しました、code =exited、status =1 / FAIL>
5月13日15:23:15testvm1systemd [1]:pcscd.service:結果'exitで失敗しました-code'。
5月13日15:23:15testvm1systemd [1]:PC/SCスマートカードデーモンを停止しました。
ほとんどのサービスの短いログエントリ表示により、このタイプの情報を見つけるためにさまざまなログファイルを検索する必要がなくなります。システムランレベルターゲットのステータスを確認します—「ターゲット」ユニットタイプを指定する必要があります:
[root @ testvm1〜]#systemctl status multi-user.target
●multi-user.target-マルチユーザーシステム
ロード済み:ロード済み(/ usr / lib / systemd / system / multi -user.target; static;ベンダープリセット:無効)
アクティブ:木2019-05-0913:27:22EDT以降アクティブ; 4日前
ドキュメント:man:systemd.special(7)
May 09 13:27:22 testvm1 systemd [1]:ターゲットのマルチユーザーシステムに到達しました。
[ root @ testvm1〜]#systemctl statusgraphical.target
●graphical.target-グラフィカルインターフェース
ロード済み:ロード済み(/usr/lib/systemd/system/graphical.target;間接;ベンダープリセット:無効)
アクティブ:2019-05-0913:27:22EDTからアクティブ。 4日前
ドキュメント:man:systemd.special(7)
May 09 13:27:22 testvm1 systemd [1]:ターゲットのグラフィカルインターフェイスに到達しました。
[root @ testvm1〜]#systemctl status default.target
●graphical.target-グラフィカルインターフェイス
ロード済み:ロード済み(/usr/lib/systemd/system/graphical.target;間接;ベンダープリセット:無効)
アクティブ:2019-05-0913:27:22EDTからアクティブ。 4日前
ドキュメント:man:systemd.special(7)
May 09 13:27:22 testvm1 systemd [1]:ターゲットのグラフィカルインターフェースに到達しました。
デフォルトのターゲットはグラフィカルターゲットです。この方法で、任意のユニットのステータスを確認できます。
マウントユニットは、指定されたマウントポイントにファイルシステムをマウントするために必要なすべてのパラメータを定義します。 systemdは、 / etc / fstabを使用する場合よりも柔軟にマウントユニットを管理できます。 ファイルシステム構成ファイル。それにもかかわらず、systemdはまだ / etc / fstabを使用しています ファイルシステムの構成とマウントを目的としたファイル。 systemdはsystemd-fstab-generatorを使用します fstabのデータから一時的なマウントユニットを作成するツール ファイル。
新しいファイルシステムとそれをマウントするsystemdマウントユニットを作成します。テストシステムに利用可能なディスク容量がある場合は、私と一緒にそれを行うことができます。
テストシステムでは、ボリュームグループと論理ボリューム名が異なる場合があることに注意してください。システムに関連する名前を使用してください。
パーティションまたは論理ボリュームを作成してから、その上にEXT4ファイルシステムを作成する必要があります。ファイルシステムにラベルを追加します、 TestFS 、マウントポイントのディレクトリを作成します / TestFS 。
これを自分で試すには、まず、ボリュームグループに空き容量があることを確認します。新しい論理ボリュームを作成するためにボリュームグループに使用可能なスペースがあるVMでは、次のようになります。
[root @ testvm1〜]#lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 120G 0 disk
├─sda10 / boot
└─sda28:2 0 116G 0 part
├─VG01-root253:0 0 5G 0 lvm /
├─VG01-swap253:1 0 SWAP]
├─VG01-usr253:2 0 30G 0 lvm / usr
├─VG01-home253:3 0 20G 0 lvm / home
├─VG01-var253:4 0 20G 0 lvm / var
└─VG01-tmp253:5 0 10G 0 lvm / tmp
sr0 11:0 1 1024M 0 rom
[root @ testvm /> VG #PV #LV #SN Attr VSize VFree
VG01 1 6 0 wz--n- <116.00g <23.00g
次に、 VG01で新しいボリュームを作成します TestFSという名前 。大きくする必要はありません。 1GBで十分です。次に、ファイルシステムを作成し、ファイルシステムラベルを追加して、マウントポイントを作成します。
[root @ testvm1〜]#lvcreate -L 1G -n TestFS VG01
論理ボリューム「TestFS」が作成されました。
[root@ testvm1〜]#mkfs -t ext4 / dev / mapper / VG01 -TestFS
mke2fs 1.45.3(14-Jul-2019)
2621444kブロックと65536iノードを使用したファイルシステムの作成
ファイルシステムUUID:8718fba9-419f-4915-ab2d-8edf811b5d23
ブロックに保存されたスーパーブロックのバックアップ:
32768、98304、163840、229376
グループテーブルの割り当て:完了完了
スーパーブロックとファイルシステムアカウンティング情報の書き込み:完了
[root @ testvm1〜]#e2label / dev / mapper / VG01-TestFS TestFS
[root @ testvm1〜]#mkdir / TestFS
次に、新しいファイルシステムをマウントします。
[root @ testvm1〜]#mount / TestFS /
mount:/ TestFS /:/ etc/fstabに見つかりません。
/ etc / fstab にエントリがないため、これは機能しません 。 / etc / fstab にエントリがなくても、新しいファイルシステムをマウントできます。 両方のデバイス名を使用します( / dev に表示されます) )とマウントポイント。この方法でのマウントは、以前よりも簡単です。これは、引数としてファイルシステムタイプを要求するために使用されていました。マウントコマンドは、ファイルシステムタイプを検出し、それに応じてマウントするのに十分スマートになりました。
もう一度お試しください:
[root @ testvm1〜]#mount / dev / mapper / VG01-TestFS / TestFS /
[root @ testvm1〜]#lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 120G0ディスク
├─sda18:1 004G0パート/ブート
└─sda2 0 0 5G 0 lvm /
├─VG01-スワップ253:1 0 8G 0 lvm [SWAP]
├─VG01-usr253:2 0 30G 0 lvm -home 253:3 0 20G 0 lvm / home
├─VG01-var253:4 0 20G 0 lvm / var
├─VG01-tmp253:5 0/0 10G>└─VG01-TestFS253:6 0 1G 0 lvm / TestFS
sr0 11:0 1 1024M 0 rom
[root @ testvm1〜]#
これで、新しいファイルシステムが適切な場所にマウントされました。マウントユニットファイルを一覧表示します:
[root@testvm1 ~]# systemctl list-unit-files -t mount
このコマンドは、 / TestFSのファイルを表示しません ファイルシステムが存在しないためです。コマンドsystemctlstatus TestFS.mount 新しいファイルシステムに関する情報も表示されません。 systemctlステータスのワイルドカードを使用して試すことができます コマンド:
[root @ testvm1〜]#systemctl status * mount
●usr.mount-/usr
ロード済み:ロード済み(/ etc / fstab;生成済み)
アクティブ:アクティブ(マウント済み)
場所:/ usr
内容:/ dev / mapper / VG01-usr
ドキュメント:man:fstab(5)
man:systemd-fstab-generator(8)
●TestFS.mount-/TestFS
ロード済み:ロード済み(/ proc / self / mountinfo)
アクティブ:アクティブ(マウント済み)2020-04金以降-17 16:02:26 EDT; 1分18秒前
場所:/ TestFS
内容:/dev/mapper/VG01-TestFS
●run-user-0.mount-/run/ user / 0
ロード済み:ロード済み(/ proc / self / mountinfo)
アクティブ:アクティブ(マウント済み)2020-04-16 08:52:29 EDT; 1日5時間前
場所:/ run / user / 0
内容:tmpfs
●var.mount-/var
ロード済み:ロード済み(/ etc / fstab;生成)
アクティブ:2020-04-16 Thu 2020-04-16 12:51:34 EDT以降アクティブ(マウント済み)。 1日前1時間
場所:/ var
内容:/ dev / mapper / VG01-var
ドキュメント:man:fstab(5)
man:systemd-fstab-generator( 8)
タスク:0(制限:19166)
メモリ:212.0K
CPU:5ms
CGroup:/system.slice/var.mount
このコマンドは、システムのマウントに関する非常に興味深い情報を提供し、新しいファイルシステムが表示されます。 / var および/usr ファイルシステムは、 / etc / fstabから生成されたものとして識別されます 、新しいファイルシステムは単にロードされていることを示し、 / proc / self / mountinfo内の情報ファイルの場所を提供します ファイル。
次に、このマウントを自動化します。まず、 / etc / fstab にエントリを追加して、昔ながらの方法で行います。 。後で、新しい方法でそれを行う方法を紹介します。これにより、ユニットを作成し、それらをスタートアップシーケンスに統合する方法について説明します。
/ TestFSのマウントを解除します 次の行を/etc / fstabに追加します ファイル:
/dev/mapper/VG01-TestFS /TestFS ext4 defaults 1 2
次に、より単純なマウントでファイルシステムをマウントします。 コマンドを実行し、マウントユニットを再度一覧表示します:
[root @ testvm1〜]#mount / TestFS
[root @ testvm1〜]#systemctl status * mount
●TestFS.mount-/TestFS
ロード済み:ロード済み(/ proc / self / mountinfo)
アクティブ:アクティブ(マウント済み)2020年4月17日金曜日16:26:44 EDT; 1分14秒前
場所:/ TestFS
内容:/ dev / mapper / VG01-TestFS
ファイルシステムが手動でマウントされたため、このマウントの情報は変更されませんでした。再起動してコマンドを再実行し、今回は TestFS.mountを指定します ワイルドカードを使用するのではなく。このマウントの結果は、起動時にマウントされているものと一致しています:
[root @ testvm1〜]#systemctl status TestFS.mount
●TestFS.mount-/TestFS
ロード済み:ロード済み(/ etc / fstab;生成済み)
アクティブ:アクティブ(マウント済み) )2020年4月17日金曜日16:30:21EDT以降。 1分38秒前
場所:/ TestFS
内容:/ dev / mapper / VG01-TestFS
ドキュメント:man:fstab(5)
man:systemd-fstab-generator(8 )
タスク:0(制限:19166)
メモリ:72.0K
CPU:6ms
CGroup:/system.slice/TestFS.mount
4月17日16:30:21testvm1systemd [1]:/TestFSをマウントしています...
4月17日16:30:21testvm1 systemd [1]:/TestFSをマウントしました。
Mount units may be configured either with the traditional /etc/fstab file or with systemd units. Fedora uses the fstab file as it is created during the installation. However, systemd uses the systemd-fstab-generator program to translate the fstab file into systemd units for each entry in the fstab ファイル。 Now that you know you can use systemd .mount unit files for filesystem mounting, try it out by creating a mount unit for this filesystem.
First, unmount /TestFS 。 Edit the /etc/fstab file and delete or comment out the TestFS ライン。 Now, create a new file with the name TestFS.mount in the /etc/systemd/system ディレクトリ。 Edit it to contain the configuration data below. The unit file name and the name of the mount point must be identical, or the mount will fail:
# This mount unit is for the TestFS filesystem
# By David Both
# Licensed under GPL V2
# This file should be located in the /etc/systemd/system directory
[Unit]
Description=TestFS Mount
[Mount]
What=/dev/mapper/VG01-TestFS
Where=/TestFS
Type=ext4
Options=defaults
[Install]
WantedBy=multi-user.target
The Description line in the [Unit] section is for us humans, and it provides the name that's shown when you list mount units with systemctl -t mount 。 The data in the [Mount] section of this file contains essentially the same data that would be found in the fstab ファイル。
Now enable the mount unit:
[root@testvm1 etc]# systemctl enable TestFS.mount
Created symlink /etc/systemd/system/multi-user.target.wants/TestFS.mount → /etc/systemd/system/TestFS.mount.
This creates the symlink in the /etc/systemd/system directory, which will cause this mount unit to be mounted on all subsequent boots. The filesystem has not yet been mounted, so you must "start" it:
[root@testvm1 ~]# systemctl start TestFS.mount
Verify that the filesystem has been mounted:
[root@testvm1 ~]# systemctl status TestFS.mount
● TestFS.mount - TestFS Mount
Loaded:loaded (/etc/systemd/system/TestFS.mount; enabled; vendor preset:disabled)
Active:active (mounted) since Sat 2020-04-18 09:59:53 EDT; 14s ago
Where:/TestFS
What:/dev/mapper/VG01-TestFS
Tasks:0 (limit:19166)
Memory:76.0K
CPU:3ms
CGroup:/system.slice/TestFS.mount
Apr 18 09:59:53 testvm1 systemd[1]:Mounting TestFS Mount...
Apr 18 09:59:53 testvm1 systemd[1]:Mounted TestFS Mount.
This experiment has been specifically about creating a unit file for a mount, but it can be applied to other types of unit files as well. The details will be different, but the concepts are the same. Yes, I know it is still easier to add a line to the /etc/fstab file than it is to create a mount unit. But this is a good example of how to create a unit file because systemd does not have generators for every type of unit.
In summary
This article looked at systemd units in more detail and how to use the systemctl command to explore and manage units. It also showed how to stop and disable units and create a new systemd mount unit to mount a new filesystem and enable it to initiate during startup.
In the next article in this series, I will take you through a recent problem I had during startup and show you how I circumvented it using systemd.
Resources
There is a great deal of information about systemd available on the internet, but much is terse, obtuse, or even misleading. In addition to the resources mentioned in this article, the following webpages offer more detailed and reliable information about systemd startup.
- The Fedora Project has a good, practical guide to systemd. It has pretty much everything you need to know in order to configure, manage, and maintain a Fedora computer using systemd.
- The Fedora Project also has a good cheat sheet that cross-references the old SystemV commands to comparable systemd ones.
- For detailed technical information about systemd and the reasons for creating it, check out Freedesktop.org's description of systemd.
- Linux.com's "More systemd fun" offers more advanced systemd information and tips.
There is also a series of deeply technical articles for Linux sysadmins by Lennart Poettering, the designer and primary developer of systemd. These articles were written between April 2010 and September 2011, but they are just as relevant now as they were then. Much of everything else good that has been written about systemd and its ecosystem is based on these papers.
- Rethinking PID 1
- systemd for Administrators, Part I
- systemd for Administrators, Part II
- systemd for Administrators, Part III
- systemd for Administrators, Part IV
- systemd for Administrators, Part V
- systemd for Administrators, Part VI
- systemd for Administrators, Part VII
- systemd for Administrators, Part VIII
- systemd for Administrators, Part IX
- systemd for Administrators, Part X
- systemd for Administrators, Part XI