Systemd 入門ガイド：コマンド編
Systemd 入門ガイド：コマンド編
Systemd 入門ガイド：コマンド編 一、由来：由来（由来） 2. Systemd 概要 ③ システム管理 3.1 systemctl 3.2 systemd-analyze 3.3 hostnamectl 3.4 localectl 3.5 timedatectl 3.6 loginctl ４、ユニット 4.1 範囲/意味 4.2 ユニットの状態 4.3 ユニット管理 依存関係 5. Unitの設定ファイル 5.1 概要 5.2 設定ファイルの状態 5.3 設定ファイルの形式 5.4 設定ファイルのブロック ⑥ ターゲット 第七、ログ管理 文書情報
著者： 阮一峰：阮一峰（阮一峰）
Systemd はLinuxシステムツールで、起動用です。 プロセスを監視するプログラム 多くのリリース版の標準設定となりました。
本文はその基本的な使い方を紹介し、上下の二篇に分けられています。今日は主なコマンドについて紹介します。
次のページ
実際に使う方法を紹介します。
一、由来：由来（由来）
歴史上、
リナックスの起動
ずっと採用しています
init
プロセス。
以下のコマンドでサービスを起動します。
xxxxxxxxxx
$ sudo /etc/init.d/apache2 start
# または
$ service apache2 start
この方法には二つの欠点があります。
一是起動時間が長い。
init
プロセスはシリアルで起動し、前のプロセスが終わるまで次が始まりません。
二に、スクリプトの起動が複雑です。
init
プロセスは起動スクリプトを実行するだけで、他のことはしない。スクリプトは自分で様々な状況を処理する必要があり、そのためスクリプトは長くなる。
2. Systemd 概要
Systemdはこれらの問題を解決するために生まれました。その設計の目的は、システムの起動と管理に包括的な解決策を提供することです。
Linuxの慣習に従って、アルファベット
d
デーモンの略です。Systemdという名前は、システム全体を守ることを意味しています。
上図はSystemdの作者です Lennart Poettering ）
Systemdを使用するので、もう必要ありません。
init
Systemdを取って代わった。
initd
システムの最初のプロセス（PIDは1）となり、他のプロセスはそのプロセスのものとされます。
xxxxxxxxxx
$ systemctl --version
上のコマンドで Systemd のバージョンを確認します。
Systemd 的优点是功能强大，使用方便，缺点是体系庞大，非常复杂。事实上，现在还有很多人反对使用 Systemd，理由就是它过于复杂，与操作系统的其他部分强耦合，违反"keep simple, keep stupid"的
Unixの哲学
（上図は Systemd 架構図です）
③ システム管理
Systemdは単一のコマンドではなく、システム管理に涉及するコマンド群です。
3.1 systemctl
systemctl
Systemdのメインコマンドで、システムを管理します。
xxxxxxxxxx
システムリブート
$ sudo systemctl reboot
システムを終了し、電源を切ります。
$ sudo systemctl poweroff
CPUが停止しました。
$ sudo systemctl halt
システム停止
$ sudo systemctl suspend
我们一起进入冬眠状态吧
システムを冬眠モードに切り替えます
私たちも一緒に冬眠モードに入りましょう
$ sudo systemctl hibernate
システムをインタラクティブなハイバーノーモードに移行します。
$ sudo systemctl hybrid-sleep
救援状態（ユーザー単一モード）に移行します
$ sudo systemctl rescue
3.2 systemd-analyze
systemd-analyze
起動時間を確認するコマンドです。
xxxxxxxxxx
# 起動時間を確認
$ systemd-analyze
# サービスごとの起動時間を確認する
$ systemd-analyze blame
# アイコンの起動プロセスを滝のように表示
$ systemd-analyze critical-chain
# 特定サービスの起動ログ表示
$ systemd-analyze critical-chain atd.service
3.3 hostnamectl
hostnamectl
コマンドは、現在のホストの情報を表示します。
xxxxxxxxxx
# 現在のホスト情報を表示
$ hostnamectl
ホスト名の設定
$ sudo hostnamectl set-hostname rhel7
3.4 localectl
localectl
创建コマンドを使用してローカライズ設定を確認します。
xxxxxxxxxx
# ローカライズ設定を確認
$ localectl
# ローカライズパラメータの設定。
$ sudo localectl set-locale LANG=en_GB.utf8
$ sudo localectl set-keymap en_GB
3.5 timedatectl
timedatectl
コマンドは現在の時帯設定を確認するために使用されます。
# 現在の時区設定を確認
$ timedatectl
# 全ての利用可能な時区を表示
$ timedatectl list-timezones
# 現在の時区を設定する
$ sudo timedatectl set-timezone America/New_York
$ sudo timedatectl set-time YYYY-MM-DD
$ sudo timedatectl set-time HH:MM:SS
3.6 loginctl
loginctl
コマンドは現在ログインしているユーザーを確認するために使われます。
xxxxxxxxxx
現在のセッションを一覧表示します。
$ loginctl list-sessions
現在のログインユーザーを一覧表示してください。
$ loginctl list-users
# 指定ユーザーの情報を表示するリストを示す
$ loginctl show-user ruanyf
４、ユニット
4.1 範囲/意味
Systemdはすべてのシステムリソースを管理できます。異なるリソースは「ユニット」と総称されます。
ユニットは12種類に分かれています。
- サービスユニット：システムサービス
- ターゲットユニット：複数のユニットで構成されるグループ
- デバイス・ユニット：ハードウェアデバイス
- マウントユニット：ファイルシステムのマウントポイント
- 自動マウントユニット：オートマウントユニット
- パスユニット：ファイルまたはパス
- Scope Unit：Systemdで起動されていない外部プロセス
- スライスユニット：プロセスグループ
- スナップショットユニット：システムドのスナップショット、特定のスナップショットに戻せる
- ソケットユニット：プロセス間通信のソケット
- Swap Unit：スワップファイル
- タイマーベースユニット
systemctl list-units
コマンドで現在のシステムのすべてのユニットを確認できます。
xxxxxxxxxx
# 現在実行中の Unit 一覧
$ systemctl list-units
すべてのUnitをリストします。設定ファイルが見つからないものや起動に失敗したものも含みます。
$ systemctl list-units --all
未実行のユニットをリストアップしてください。
$ systemctl list-units --all --state=inactive
# 加载に失敗したすべての Unit をリストアップ
$ systemctl list-units --failed
すべての実行中のserviceタイプのUnitをリストアップしてください。
$ systemctl list-units --type=service
4.2 ユニットの状態
systemctl status
コマンドは、システム状態と個々のユニットの状態を確認するために使用されます。
xxxxxxxxxx
システムの状態を表示してください。
$ systemctl status
# 単一ユニットの状態を表示
$ sysystemctl status bluetooth.service
# リモートホストの特定のユニットの状態を表示
$ systemctl -H root@rhel7.example.com status httpd.service
除えて
status
命令：命令です。
systemctl
3つのクエリ状態の簡単な方法を提供しました。主にスクリプト内の判定文で使用されます。
xxxxxxxxxx
# 指定の Unit が実行中かどうかを表示
$ systemctl is-active application.service
# 指定のUnitが起動失敗状態かどうかを表示
$ systemctl is-failed application.service
# Unitサービスが起動リンクを確立しているか確認
$ systemctl is-enabled application.service
4.3 ユニット管理
ユーザーが最もよく使うコマンドは以下の通りです。これらはUnit（主にservice）を起動・停止するためのものです。
xxxxxxxxxx
サービスをすぐに開始してください。
$ sudo systemctl start apache.service
サービスをすぐに停止してください。
$ sudo systemctl stop apache.service
サービスを再起動します
$ sudo systemctl restart apache.service
サービスのすべてのサブプロセスを終了する
$ sudo systemctl kill apache.service
サービスの設定ファイルを再読み込みします。
$ sudo systemctl reload apache.service
全ての変更された設定ファイルをリロードします。
$ sudo systemctl daemon-reload
# 某個ユニットの全ての下位パラメータを表示
$ systemctl show httpd.service
时间戳
# 表示时间戳的属性
timestamp = 1640995200
# 指定 Unit
unit = "UnitName"
# 指定属性
attribute = "Attribute"
# 获取指定 Unit 的指定属性的值
value = get_attribute_value(unit, attribute)
# 込出时间戳和属性值
print("Timestamp: ", timestamp)
print("Attribute: ", value)
$ systemctl show -p CPUShares httpd.service
# 指定ユニットの属性を設定する
$ sudo systemctl set-property httpd.service CPUShares=500
依存関係
ユニット間に依存関係：AがBに依存する場合、SystemdはAを起動するときにBも同時に起動します。
systemctl list-dependencies
Unitの全ての依存関係をリストアップしてください。
xxxxxxxxxx
$ systemctl list-dependencies nginx.service
上記のコマンドの出力結果の中には、ターゲットタイプの依存関係があります（詳細は以下を参照してください）。デフォルトでは、ターゲットは展開されません。ターゲットを展開するには、次のようにします：
--all
パラメータ。
xxxxxxxxxx
$ systemctl list-dependencies --all nginx.service
5. Unitの設定ファイル
5.1 概要
各 Unit には設定ファイルがあり、それが Systemd に Unit の起動方法を指示します。
systemdデフォルトのディレクトリ
/etc/systemd/system/
設定ファイルを読み込みます。しかし、その中には多くのシンボリックリンクがあり、それがディレクトリを指しています。
/usr/lib/systemd/system/
実際の設定ファイルはそのディレクトリにあります。
systemctl enable
コマンドは、その2つのディレクトリ間にシンボリックリンクを作成するために使用されます。
xxxxxxxxxx
$ sudo systemctl enable clamd@scan.service
同等に
$ sudo ln -s '/usr/lib/systemd/system/clamd@scan.service' '/etc/systemd/system/multi-user.target.wants/clamd@scan.service'
設定ファイルで起動時の開始が設定されていました。
systemctl enable
コマンドは起動のトリガーに相当します。
それに対して、
systemctl disable
コマンドは、2つのディレクトリ間のシンボリックリンクを解除するために使用され、起動時のロードを解除するのに相当します。
xxxxxxxxxx
$ sudo systemctl disable clamd@scan.service
設定ファイルの拡張子は、その Unit の種類を示します。例えば、
sshd.socket
省略すると、Systemdのデフォルトの接尾辞は
.service
だからって
sshd
誤解されるかも
sshd.service
。
5.2 設定ファイルの状態
systemctl list-unit-files
コマンドはすべての設定ファイルをリストします。
xxxxxxxxxx
# すべての設定ファイルをリストアップしてください。
$ systemctl list-unit-files
# 指定タイプの設定ファイルを一覧表示する
$ systemctl list-unit-files --type=service
このコマンドはリストを出力します。
xxxxxxxxxx
$ systemctl list-unit-files
UNIT FILE STATE
chronyd.service enabled
clamd@.service static
clamd@scan.service disabled
このリストは各設定ファイルの状態を示しており、合計で4種類あります。
- enabled: 启動リンク已建立
- 未設定：起動リンク未設定
-
static：この設定ファイルはありません
[Install]（実行不可）、他の設定ファイルの依存関係としてのみ利用可 - マスクド：この設定ファイルはスタートリンクの作成が禁止されています
注意：設定ファイルの状態から、このUnitが運行中かどうかは分かりません。これは前面で述べたことと同じです。
systemctl status
命令です。
xxxxxxxxxx
$ systemctl status bluetooth.service
設定ファイルを変更したら、SystemDが設定ファイルを再読み込みし、再起動させる必要があります。それしないと変更は反映されません。
xxxxxxxxxx
$ sudo systemctl daemon-reload
$ sudo systemctl restart httpd.service
5.3 設定ファイルの形式
設定ファイルは通常のテキストファイルで、テキストエディタで開けます。
systemctl cat
コマンドで設定ファイルの内容を確認できます。
xxxxxxxxxx
$ systemctl cat atd.service
[Unit]
Description=ATD daemon
[Service]
Type=forking
ExecStart=/usr/bin/atd
[Install]
WantedBy=multi-user.target
上記の表示から、設定ファイルはいくつかのブロックに分かれています。各ブロックの最初の行は、括弧で示される識別名で、例えば：
[Unit]
注意：設定ファイルのブロック名とフィールド名は、大文字小文字が区別されます。
各ブロック内には、等号で結ばれたキー値対があります。
xxxxxxxxxx
[Section]
Directive1=value
Directive2=value
. . .
5.4 設定ファイルのブロック
[Unit]
ブロックは通常、設定ファイルの最初のブロックで、Unitのメタデータや他のUnitとの関係を定義するために使用されます。主なフィールドは以下の通りです。
-
Dsecription簡潔に説明 -
Documentation：ドキュメントのURL -
Requires現在の Unit が依存する他の Unit が動作していない場合、現在の Unit の起動に失敗します。 -
Wants現在の Unit と連携している他の Unit が動作していない場合、現在の Unit は起動失敗しません。 -
BindsTo：とRequires類似で、指定されたUnitが退出すると、現在のUnitの動作が停止します -
Before：指定のUnitが起動する場合、そのUnitは現在のUnitの後で起動する必要があります。 -
After：指定のUnitが起動する必要がある場合、そのUnitは現在のUnitより前に起動する必要があります。 -
Conflicts指定のUnitは現在のUnitと同時に実行できません。 -
Condition...現在の Unit が実行するための必須条件、それが満たされないと実行されません。 -
Assert...現在のUnitの動作には満たす必要のある条件があります。それが満たされないと、起動失敗が報告されます。
[Install]
通常は設定ファイルの最後のセクションで、起動方法や自動起動の有無を定義します。主なフィールドは以下の通りです。
-
WantedByその値は、ターゲットの1つまたは複数です。現在のユニットが有効（enable）時、シンボリックリンクが格納されます。/etc/systemd/systemカタログの下に Target 名 +.wants接尾辞で作成されたサブディレクトリ -
RequiredByその値は1つ以上のTargetで、現在のUnitがアクティブな際にシンボリックリンクが設定されます。/etc/systemd/systemカタログの下に Target 名 +.required接尾辞で作成されたサブディレクトリ -
Alias現在の Unit が利用できるエイリアス -
Also現在の Unit 活動（有効）中、同時に活性化される他の Unit
[Service]
ブロックはServiceの設定に用い、Service型のUnitのみがこのブロックを持っています。主要なフィールドは以下の通りです。
-
Typeプロセスの起動時の挙動を定義します。以下の値があります。 -
Type=simpleデフォルト値、実行ExecStart指定のコマンドでメインプロセスを起動します。 -
Type=forking親プロセスからforkメソッドで子プロセスを作成し、作成後親プロセスはすぐに終了します。 -
Type=oneshot一時的なプロセス、Systemdは現在のサービスが終了するまで待ち、その後続行します -
Type=dbus現在のサービスはD-Busで起動しています。 -
Type=notify現在サービスが開始されました。通知します。Systemdさらに下に進む。 -
Type=idle他のタスクが終わったら、そのサービスが動く。 -
ExecStart現在のサービスを起動するコマンド -
ExecStartPreサービスを開始する前に実行するコマンド -
ExecStartPostサービスを開始後の実行コマンド -
ExecReload現在のサービスを再起動する際に実行するコマンド -
ExecStop現在のサービスを停止する際に実行するコマンド -
ExecStopPostサービス停止後の命令を停止 -
RestartSec現在のサービスの自動再起動の間隔（秒） -
RestartSystemdが自動でサービスを再起動する定義される条件：可能な値は以下の通りです。alwaysいつも再起動、on-success、on-failure、on-abnormal、on-abort、on-watchdog -
TimeoutSecSystemdが現在のサービスを停止する前に待つ秒数を定義 -
Environment指定環境変数
Unit設定ファイルの完全なフィールドリストは、参照してください。 公式文書
⑥ ターゲット
コンピュータの起動時に多くの Unit を起動する必要があります。毎回、起動する Unit を一つずつ指定するのは非常に不便です。Systemd は、その解決策として Target を提供しています。
简单说，Target 就是一个 Unit 组，包含许多相关的 Unit 。启动某个 Target 的时候，Systemd 就会启动里面所有的 Unit。从这个意义上说，Target这个概念类似于"状态点"，启动某个 Target 就好比启动到某种状态。
伝統的
init
起動モードには RunLevel という概念があり、Targetと似ているが、RunLevelは排他で複数が同時に起動できない。一方で、複数のTargetは同時に起動可能。
xxxxxxxxxx
現在のシステムのすべてのターゲットを確認する
$ systemctl list-unit-files --type=target
ターゲットに含まれるすべてのユニットを確認する
$ systemctl list-dependencies multi-user.target
# 起動時のデフォルトのターゲットを確認
$ systemctl get-default
# 設定起動時のデフォルトのターゲット
$ sudo systemctl set-default multi-user.target
ターゲットの切り替え時、前のターゲットで開始したプロセスをデフォルトで閉じない。
#systemctl isolateコマンドでこの行動を変更します
ターゲットの前のすべてのプロセスを終了し、後のターゲットに属さないものを除外
$ sudo systemctl isolate multi-user.target
ターゲットと伝統的なRunLevelの対応関係は以下の通りです。
xxxxxxxxxx
Traditional runlevel New target name Symbolically linked to...
Runlevel 0 | runlevel0.target -> poweroff.target
Runlevel 1 | runlevel1.target -> rescue.target
Runlevel 2 | runlevel2.target -> multi-user.target
Runlevel 3 | runlevel3.target -> multi-user.target
Runlevel 4 | runlevel4.target -> multi-user.target
Runlevel 5 | runlevel5.target -> graphical.target
Runlevel 6 | runlevel6.target -> reboot.target
それは
init
進行の主な違いは以下の通りです。
デフォルトのRunLevel
（在
/etc/inittab
（ファイル設定）は今やデフォルトのターゲットに置き換えられました。場所は
/etc/systemd/system/default.target
当然、一般的に、シンボリックリンクは
graphical.target
（グラフィックユーザインターフェース）または
multi-user.target
（マルチユーザーコマンドライン）
（2）スクリプトの起動場所
以前は、
/etc/init.d
目次、シンボリックリンクは異なるRunLevelディレクトリに指している（例えば）
/etc/rc3.d
、
/etc/rc5.d
現在は、（ここに）、所蔵されています。
/lib/systemd/system
「わ」
/etc/systemd/system
目次。
（3）設定ファイルの場所
以前：以前に
init
プロセスの設定ファイルは
/etc/inittab
各種サービスの設定ファイルは、
/etc/sysconfig
目次。現在の設定ファイルは主に以下に保存されています。
/lib/systemd
目次、在
/etc/systemd
目次の修正は元の設定を上書きできます。
第七、ログ管理
SystemdがすべてのUnitの起動ログを統一管理します。これにより、利用できる利点は次の通りです：
journalctl
一つのコマンドで、すべてのログ（カーネルログおよびアプリケーションログ）を確認します。ログの設定ファイルは
/etc/systemd/journald.conf
。
journalctl
機能豊富、用途多岐にわたる。
# 全てのログを確認する（デフォルトでは、現在の起動時のログのみ保存）
$ sudo journalctl
# カーネルログを確認（アプリケーションログは表示しない）
$ sudo journalctl -k
システムの起動ログを確認してください。
$ sudo journalctl -b
$ sudo journalctl -b -0
前回起動のログを確認（設定変更必要）
$ sudo journalctl -b -1
指定時刻の日誌を見る
$ sudo journalctl --since="2012-10-30 18:17:16"
$ sudo journalctl --since "20 min ago"
$ sudo journalctl --since yesterday
$ sudo journalctl --since "2015-01-10" --until "2015-01-11 03:00"
$ sudo journalctl --since 09:00 --until "1 hour ago"
# 最新10行ログを表示する
$ sudo journalctl -n
# 表示するログの末尾の指定行数を表示する
$ sudo journalctl -n 20
リアルタイムで最新のログをスクロール表示
$ sudo journalctl -f
指定サービスのログを確認してください。
$ sudo journalctl /usr/lib/systemd/systemd
指定プロセスのログを確認する
$ sudo journalctl _PID=1
# ルートのスクリプトのログを確認する
$ sudo journalctl /usr/bin/bash
指定ユーザーのログを確認してください。
$ sudo journalctl _UID=33 --since today
# 某個ユニットのログを確認する
$ sudo journalctl -u nginx.service
$ sudo journalctl -u nginx.service --since today
# 某特定ユニットの最新ログのリアルタイム表示
$ sudo journalctl -u nginx.service -f
# 多ユニットのログを統合表示
$ journalctl -u nginx.service -u php-fpm.service --since today
指定の優先度（その以上のレベル）のログを確認します。全8レベルです。
# 0: emerg
# 1: alert
# 2: crit
# 3: err
# 4: warning
# 5: notice
# 6: info
# 7: debug
$ sudo journalctl -p err -b
# デフォルトでログはページ単位で表示されます。--no-pagerを指定すると、標準出力に変更されます。
$ sudo journalctl --no-pager
```json
{
"以JSON格式（单行）输出": "JSON形式で（一行で）出力してください"
}
```
$ sudo journalctl -b -u nginx.service -o json
以下は、あなたの提供する中国語の文章をJSON形式で簡略化して翻訳したものです。
```json
{
"translation": "以下は、あなたの提供する中国語の文章をJSON形式で簡略化して翻訳したものです。"
}
```
$ sudo journalctl -b -u nginx.serviceqq
-o json-pretty
ログが占めるハードディスクの空き容量を表示
$ sudo journalctl --disk-usage
指定ログファイルの最大占有サイズ
$ sudo journalctl --vacuum-size=1G
指定ログファイルの保存期間はどれくらいですか？
$ sudo journalctl --vacuum-time=1years
（終了）
文書情報
- 著作権表示：自由転載-非商業用途-非派生作品-原著者表示 クリエイティブ・シェア3.0 ライセンス )
- 発行日：2016年3月7日
最近使用した：