SystemD - SystemD は何に使用されますか?

SystemD は、システム管理タスクを合理化し、効率を向上させるために使用されるシステム管理ツールです。その主な利点は、システムのパフォーマンスと応答性を向上させる機能と、脆弱性を自動的にスキャンしてパッチを適用することでセキュリティを向上させる機能にあります。

さらに、SystemD はシステム リソースをより効果的に編成するのに役立ち、プログラムをより高速かつスムーズに実行できるようにします。全体として、システムを最大限に活用するのに役立つ効果的なシステム管理ツールを探している場合、SystemD は理想的なソリューションです。この記事では、SystemD について知っておく必要があるすべてのことを学びます。

SystemD は何に使用されますか?

SystemD は、システム リソースとプロセスの管理から、Linux システムでのシステム パフォーマンスの最適化まで、さまざまなタスクに使用できるシステム管理ツールです。その強力な機能と高度な機能により、医療から製造まで、さまざまな業界で広く使用されています。

大規模なサーバーを実行している場合でも、小規模なワークステーションを実行している場合でも、SystemD は、システムの効率と生産性の向上に役立つさまざまな利点を提供します。主な機能には、プロセスの優先順位付け、システム イベントのログ記録、システム リソース割り当ての制御などがあります。そのため、組織がすべてのシステムの効率とパフォーマンスを向上させる信頼できるシステム管理ツールを探しているなら、SystemD は間違いなく検討する価値があります。

なぜ人々は SystemD を嫌うのですか?

多くのユーザーは SystemD が非常に貴重なシステム管理ツールであると感じていますが、さまざまな理由で SystemD を嫌うユーザーもいます。一部の批評家は、特にシステム管理タスクに慣れていない人にとっては、非常に複雑で使いにくいと主張しています。また、システム パフォーマンスに悪影響を及ぼし、起動時間が遅くなり、リソース使用量が増加する可能性があると主張する人もいます。

これらの懸念にもかかわらず、SystemD は現在でも市場で最も広く使用されているシステム管理ツールの 1 つであり、今後もそうであり続けるでしょう。組織のシステム全体の生産性を向上させる効率的なシステム管理ツールを探しているなら、SystemD は間違いなく検討する価値があります。

SystemD が論争の的になっているのはなぜですか?

SystemD は、主にその有効性と使いやすさに関する進行中の議論のために、非常に物議を醸すシステム管理ツールです。システムのパフォーマンスに悪影響を与える可能性があると主張するユーザーもいれば、システム セキュリティの向上やシステム リソースの割り当ての効率化など、多くの重要なメリットがあると主張するユーザーもいます。

SystemD の複雑さと使いやすさについても懸念があり、多くのユーザーは、その急な学習曲線とわかりにくいインターフェースを主な批判点として挙げています。これらの懸念にもかかわらず、SystemD は今日の市場で最も広く使用されているシステム管理ツールの 1 つであり、今後もそうであり続ける可能性があります。すべてのシステムでシステムのパフォーマンスと効率を向上させる強力なシステム管理ツールを探しているなら、SystemD が理想的なソリューションかもしれません。

SystemD と init とは?

SystemD と init は、よく似た機能と重複する機能のために比較されるシステム管理ツールです。どちらのシステム管理ツールも、プロセスの優先順位付け、システム イベントのログ記録、システム リソース割り当ての制御など、さまざまなシステム管理タスクに使用できますが、両者にはいくつかの重要な違いがあります。

たとえば、init はシステムの起動とシャットダウンのプロセスに重点を置いていますが、SystemD はより幅広いシステム管理機能を提供します。さらに、多くのユーザーは、SystemD が init よりもユーザーフレンドリーで直感的であることを認識しており、システム管理者や IT プロフェッショナルの間で SystemD が人気のある選択肢となっています。全体として、すべてのシステムでシステムのパフォーマンスと効率を向上させる効果的なシステム管理ソリューションを探しているなら、SystemD が理想的な選択肢かもしれません。

Grub または SystemD を使用する必要がありますか?

Grub と SystemD にはそれぞれ利点と欠点があるため、この質問に対する決定的な答えはありません。一方では、Grub は、システムの起動とシャットダウンのためのシンプルで合理化された機能を提供する軽量のシステム管理ツールです。

一方、SystemD はより幅広いシステム管理機能と機能を提供するため、より強力で用途の広いシステム管理ツールとなっています。最終的に、Grub と SystemD のどちらを使用するかは、システム管理者または IT プロフェッショナルとしての特定のニーズと好みによって異なります。ただし、すべてのシステムでシステムのパフォーマンスと効率を向上させるのに役立つ効率的なシステム管理ソリューションを探している場合は、SystemD の方が適している可能性があります。

SystemD の使い方

次に、Linux システムで SystemD を使用するいくつかの方法について説明します。これらは、自分で試すことができるほんの一例です。構文に慣れるには少し時間がかかりますが、慣れると SystemD は強力なツールになります。

SystemD - 初期化

これはカーネルによって開始された最初のプロセスであり、プロセス ID 1 を取得します .ソケットの作成、ハードウェアのセットアップ、ディスクのマウントなどのタスクのブート プロセスを管理します。

SystemD は、さまざまなタイプのユニットで動作します。サービス自体の隣には、次のものもあります:

• タイマー
• マウント
• ネットワーク
• ソケット
• パーティション
• デバイス

さらに、SystemD を使用して他のプロセスを管理することもできます:

• 開始
• やめる
• 再起動
• 殺す

ユニットファイル

既存のユニット ファイルにはさまざまなパスがあります:

パス	情報
/usr/lib/systemd/system	定義済みの SystemD ファイル (変更しないでください)
/etc/systemd/system	カスタム ユニット ファイルの場所
/run/systemd/system	実行時関連ファイル

パスに関する重要な情報: SystemD は常に /etc/ を /usr/lib/ より優先します .これが、カスタム ユニット ファイルをそこに配置する理由です。

パスにアクセスするか、次のコマンドを使用して、特定のサービスのユニット ファイルにアクセスできます。

systemctl cat <service>
Code language: Bash (bash)

たとえば、OpenVPN:

[email protected]:~$ systemctl cat openvpn
# /lib/systemd/system/openvpn.service
# This service is actually a systemd target,
# but we are using a service since targets cannot be reloaded.

[Unit]
Description=OpenVPN service
After=network.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true
WorkingDirectory=/etc/openvpn

[Install]
WantedBy=multi-user.target
Code language: Bash (bash)

ユニット ファイルでわかるように、使用するパスを定義します。 、PID ファイル 、その他のオプション .これについては、以下で詳しく説明します。コマンドを使用して、サービスのユニット ファイルで定義できるオプションを使用して、使用可能なすべてのプロパティを表示できます。

systemctl show <service>
Code language: Bash (bash)

たとえば、ここでも、OpenVPN の出力の最初の行は次のとおりです。

[email protected]:~$ systemctl show openvpn
Type=oneshot
Restart=no
NotifyAccess=none
RestartUSec=100ms
TimeoutStartUSec=infinity
TimeoutStopUSec=1min 30s
TimeoutAbortUSec=1min 30s
TimeoutStartFailureMode=terminate
TimeoutStopFailureMode=terminate
RuntimeMaxUSec=infinity
WatchdogUSec=0
WatchdogTimestamp=n/a
WatchdogTimestampMonotonic=0
RootDirectoryStartOnly=no
RemainAfterExit=yes
GuessMainPID=yes
MainPID=0
ControlPID=0
FileDescriptorStoreMax=0
NFileDescriptorStore=0
StatusErrno=0
Result=success
ReloadResult=success
CleanResult=success
UID=[not set]
GID=[not set]
NRestarts=0
OOMPolicy=stop
ExecMainStartTimestamp=Sat 2022-09-17 13:00:55 CEST
ExecMainStartTimestampMonotonic=9823235
ExecMainExitTimestamp=Sat 2022-09-17 13:00:55 CEST
ExecMainExitTimestampMonotonic=9824084
ExecMainPID=1164
ExecMainCode=1
ExecMainStatus=0v
Code language: Bash (bash)

サービスのユニット ファイルを編集する場合は、次のコマンドを実行します。

systemctl edit – full <service>
Code language: Bash (bash)

full なしでコマンドを実行すると オプションを指定すると、空のファイルが取得されます。編集可能なソース ファイルのコピーを作成するオプションがあります。

可能なオプションの例として、OpenVPN を常に実行したいとします。プロセスが停止または強制終了された場合でも、自動的に再起動する必要があります。

エディタを開き、特定のオプションを追加します:

# This service is actually a systemd target,
# but we are using a service since targets cannot be reloaded.

[Unit]
Description=OpenVPN service
After=network.target

[Service]
Restart=yes
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true
WorkingDirectory=/etc/openvpn

[Install]
WantedBy=multi-user.target
Code language: Bash (bash)

この後、構成ファイルをリロードする必要があります:

systemctl reload <service>
Code language: Bash (bash)

最後に、サービスを再起動します:

systemctl restart <service>
Code language: Bash (bash)

このコマンドを使用すると、SystemD はサービスの再読み込みを試みます。これが機能しない場合は、サービスを再起動します:

systemctl reload-or-restart <service>
Code language: HTML, XML (xml)

上記のコマンドでは、サービスを手動で制御する方法を学びました。 SystemD では、サービスを永続的に有効または無効にして、必要なときに自動的に開始するか、まったく利用できないようにすることもできます。次の表に、使用可能なコマンドを示します:

コマンド	機能
有効	サービスを有効にします
無効	サービスを無効にします
有効	サービスが有効になっているかどうかを確認
再有効化	サービスを無効にしてから再度有効にする
マスク	サービスを完全に無効にしたい場合は、彼をマスクしてください - 注意してください
アンマスク	サービスのマスクを解除します

使用例:

systemctl enable <service>
Code language: Bash (bash)

ターゲット

これらは、システムが起動できるさまざまな状態です。

SystemD は、よく知られている実行レベルに新しい概念を追加します。ただし、古い原則は保持されます。番号の代わりに実行レベルのみに名前が付けられます:

ターゲット	効果
halt.target	システムをシャットダウン
poweroff.target	システムを物理的にシャットダウンします (電源オフ)
rescue.target	シングル ユーザー モード
multi-user.target	マルチユーザー モード
graphical.target	グラフィカル インターフェースによるマルチユーザー モード
reboot.target	システムを再起動します

次のコマンドを使用して、別のターゲットに切り替えることができます:

systemctl isolate example.target
Code language: Bash (bash)

システムを再起動します:

systemctl reboot
Code language: Bash (bash)

システムをディープ スリープ状態にし、実行中のすべてのプロセスを一時停止します。

systemctl hybrid-sleep
Code language: Bash (bash)

ログインしているすべてのユーザーにブロードキャスト メッセージを送信して、システムの電源をオフにします。

systemctl shutdown

パラメータを使用してこれを変更できます:

systemctl shutdown -r now
Code language: Bash (bash)

これにより、システムが再起動され (-r)、ブロードキャスト メッセージがバイパスされ、直接再起動されます。このコマンドを使用するためのさまざまなパラメーターがあります。マンページで調べることができます。

次のコマンドを使用して、システムが起動している現在のターゲットを表示できます:

systemctl get-default
Code language: Bash (bash)

さらに、ターゲットを変更できます:

systemctl set-default example.target
Code language: Bash (bash)

さまざまなランレベルもここで確認できます:

ls -la /usr/lib/systemd/system |grep runle*
Code language: Bash (bash)

[email protected]:~$ ls -la /usr/lib/systemd/system |grep runle*
lrwxrwxrwx  1 root root    15 Apr 18 22:12 runlevel0.target -> poweroff.target
lrwxrwxrwx  1 root root    13 Apr 18 22:12 runlevel1.target -> rescue.target
drwxr-xr-x  2 root root  4096 Jan 28  2022 runlevel1.target.wants
lrwxrwxrwx  1 root root    17 Apr 18 22:12 runlevel2.target -> multi-user.target
drwxr-xr-x  2 root root  4096 Jan 28  2022 runlevel2.target.wants
lrwxrwxrwx  1 root root    17 Apr 18 22:12 runlevel3.target -> multi-user.target
drwxr-xr-x  2 root root  4096 Jan 28  2022 runlevel3.target.wants
lrwxrwxrwx  1 root root    17 Apr 18 22:12 runlevel4.target -> multi-user.target
drwxr-xr-x  2 root root  4096 Jan 28  2022 runlevel4.target.wants
lrwxrwxrwx  1 root root    16 Apr 18 22:12 runlevel5.target -> graphical.target
drwxr-xr-x  2 root root  4096 Jan 28  2022 runlevel5.target.wants
lrwxrwxrwx  1 root root    13 Apr 18 22:12 runlevel6.target -> reboot.target
-rw-r--r –  1 root root   803 Apr 18 22:12 systemd-update-utmp-runlevel.service
Code language: plaintext (plaintext)

コントロール グループ

SystemD はタスクをコントロール グループにまとめます。これは Linux でのリソース制御に使用され、利用可能なリソースを制限できます。 、優先 、カウント、 そして孤立 .

したがって、次のコマンドは、システム パフォーマンスの分析と最適化に非常に役立ちます。

systemd-analyze
Code language: Bash (bash)

このコマンドは、起動パフォーマンスを決定するために使用できます。

[email protected]:~$ systemd-analyze
Startup finished in 12.712s (firmware) + 328ms (loader) + 8.240s (kernel) + 6.634s (userspace) = 27.916s 
graphical.target reached after 6.631s in userspace
Code language: plaintext (plaintext)

ご覧のとおり、各タスクの開始にかかる時間の内訳が得られます。

追加コマンド blame で どの単一プロセスを起動するのにどれくらいの時間が必要かについて、非常に詳細なリストが得られます:

systemd-analyze blame

出力 :

[email protected]:~$ systemd-analyze blame
5.573s NetworkManager-wait-online.service
3.244s plymouth-quit-wait.service
2.285s fwupd.service
 467ms logrotate.service
 392ms lm-sensors.service
 385ms accounts-daemon.service
 362ms snapd.service
 290ms systemd-resolved.service
 279ms networkd-dispatcher.service
 247ms networking.service
 213ms dev-nvme0n1p3.device
 182ms apparmor.service
 178ms ModemManager.service
 174ms systemd-journal-flush.service
 168ms udisks2.service
 161ms NetworkManager.service
 152ms com.system76.Scheduler.service
 128ms apport.service
 127ms e2scrub_reap.service
 116ms rsyslog.service
 115ms smartmontools.service
 114ms wpa_supplicant.service
 105ms [email protected]
 100ms gpu-manager.service
....
Code language: plaintext (plaintext)

すべてのコントロール グループを表示する場合は、次を使用できます。

systemd-cgls
Code language: Bash (bash)

または

systemctl status
Code language: Bash (bash)

必要なすべての情報を含むツリーベースの出力が得られます:

[email protected]:~$ systemd-cgls
Control group /:
-.slice
├─user.slice 
│ └─user-1000.slice 
│   ├─[email protected] 
│   │ ├─session.slice 
│   │ │ ├─dbus-broker.service 
│   │ │ │ ├─3119 /usr/bin/dbus-broker-launch – scope user
│   │ │ │ └─3120 dbus-broker – log 4 – controller 10 – machine-id 04d8535513777afc7bb291c362dd90a7 – max-bytes 100000000000000 – max-fds 25000000000000 – max-matches 50000000>
│   │ │ ├─xdg-document-portal.service 
│   │ │ │ ├─3761 /usr/libexec/xdg-document-portal
│   │ │ │ └─3773 fusermount3 -o rw,nosuid,nodev,fsname=portal,auto_unmount,subtype=portal – /run/user/1000/doc
│   │ │ ├─xdg-desktop-portal.service 
│   │ │ │ └─3753 /usr/libexec/xdg-desktop-portal
│   │ │ ├─pipewire-pulse.service 
│   │ │ │ └─3112 /usr/bin/pipewire-pulse
│   │ │ ├─wireplumber.service 
│   │ │ │ └─3111 /usr/bin/wireplumber
│   │ │ ├─plasma-xdg-desktop-portal-kde.service 
│   │ │ │ └─3861 /usr/lib/x86_64-linux-gnu/libexec/xdg-desktop-portal-kde
│   │ │ └─pipewire.service 
│   │ │   └─3106 /usr/bin/pipewire
│   │ ├─background.slice 
│   │ │ ├─plasma-kactivitymanagerd.service 
│   │ │ │ └─3546 /usr/lib/x86_64-linux-gnu/libexec/kactivitymanagerd
│   │ │ ├─plasma-kscreen.service 
│   │ │ │ └─3610 /usr/lib/x86_64-linux-gnu/libexec/kf5/kscreen_backend_launcher
│   │ │ ├─plasma-baloorunner.service 
│   │ │ │ └─5633 /usr/lib/x86_64-linux-gnu/libexec/baloorunner
│   │ │ ├─plasma-kglobalaccel.service 
│   │ │ │ └─3452 /usr/bin/kglobalaccel5
│   │ │ └─tracker-miner-fs-3.service 
│   │ │   └─3148 /usr/libexec/tracker-miner-fs-3
│   │ ├─app.slice 
│   │ │ ├─app-\\x2fusr\\x2fbin\\x2fkorgac-d27ecb9065d646918a10df1c4fa798fe.scope 
│   │ │ │ └─3599 /usr/bin/korgac -session 10dfe2702d000165869202400000083140007_1663442587_18526
│   │ │ ├─gvfs-goa-volume-monitor.service 
│   │ │ │ └─3171 /usr/libexec/gvfs-goa-volume-monitor
│   │ │ ├─app-dbus\\x2d:1.2\\x2dorg.gnome.OnlineAccounts.slice 
│   │ │ │ └─dbus-:[email protected] 
│   │ │ │   └─3174 /usr/libexec/goa-daemon
│   │ │ ├─xdg-permission-store.service 
│   │ │ │ └─3765 /usr/libexec/xdg-permission-store
│   │ │ ├─com.system76.SystemUpdater.Local.service 
Code language: plaintext (plaintext)

systemd-cgtop で コマンドを実行すると、現在のリソース使用率でソートされたすべてのコントロール グループのリストが取得されます:

systemd-cgtop
Code language: Bash (bash)

では、なぜこれが私たちにとって重要なのでしょうか?これで、個々のプロセスのリソース使用率を分析し、必要に応じてプロセスの優先度を調整したり、リソース制限を変更したりできます。

man ページには、これを管理する多くの可能性が示されています。

man systemd.resource-control
Code language: Bash (bash)

たとえば、特定のサービスのメモリ制限を設定する場合は、次を使用できます。

systemctl set property example.service MemoryLimit=1G
Code language: Bash (bash)

ロギング - JournalD

JournalD は、すべてのイベントをシステムの RAM に記録します。これは、システムの再起動でクリアされます。

次のコマンドで JournalD を使用できます:

journalctl
Code language: Bash (bash)

たとえば、特定の時間でフィルターを追加することにより、出力をさらに絞り込むことができます。

journalctl – since yesterday
Code language: Bash (bash)

から までの正確な期間を指定することで、さらに絞り込むことができます:

journalctl – since "date" – until "date"
Code language: Bash (bash)

フィルタリングするもう 1 つの方法は、特定のサービスをフォローすることです:

journalctl -u example
Code language: Bash (bash)

特定のサービスをフォローして、このサービスだけをフィルタリングすることもできます:

journalctl -fu example
Code language: Bash (bash)

カーネル イベントのみをフィルタリングすることもできます。

journalctl -k
Code language: Bash (bash)

まとめ

SystemD は、従来の System V init デーモンの強力な後継であり、日常の作業とワークフローを高速化するための多くの有用な情報とツールを管理者に提供します。その他の詳細な Linux トピックについて詳しく知りたい場合は、Max Wilke のブログにアクセスしてください。

• SystemD は、システム リソースの管理などのタスクに使用できるシステム管理ツールです。 とプロセス 、システム パフォーマンスの最適化 、セキュリティの向上 .
• SystemD は、組織の効率と生産性の向上に役立つ多くのメリットを提供します 、プロセスの優先順位付けを含む 、システム イベント ロギング 、リソース割り当ての制御 .
• SystemD はその強力な機能により、さまざまな業界で広く使用されていますが、一部のユーザーは、複雑または使いにくいという理由でそれを嫌っています .さらに、一部の批評家は、システム パフォーマンスに悪影響を与える可能性があると主張しています。 .
• これらの懸念にもかかわらず、SystemD は今日の市場で最も人気のあるシステム管理ツールの 1 つです。