前回の記事「Systemd」を理解するーシステム起動編ーでは、Systemdの概念とSystemdによるLinux起動プロセスの内容を解説させていただいた。第二回となる今回の記事では、Systemdを利用したシステムの管理方法を記載していきたいと思う。
今回の記事ではSystemdのsystemctlコマンドを利用したサービス（プロセス）管理方法と、journalctlコマンドを利用したSystemd journalログ照会の2章立てでSystemdによるシステム管理を解説させていただく。また、各コマンドは先日リリースされたCentOS7上で動作確認させていただいた。
systemctlを利用してサービスを管理する
Systemd環境にてサービス管理を行う場合、主にsystemctlコマンドを利用するが、一部、従来のコマンドも利用可能となっている。使途別のコマンドを見ていこう。
Unitの起動／停止／再起動など
前回の記事でも説明させていただいたが、Systemd上で起動するサービスや各種ファイルシステムのマウント、ソケットの監視等の振る舞いは全てUnitとして表現される。systemctlコマンドを利用することで、これらのUnitの起動／停止（Unitはサービスに限った話ではないので、有効化・無効化とも表現できる）を行う事ができる。
systemctl [Unitコマンド] [Unit名]
Unitコマンドには以下の種類がある。この辺の考え方は従来のserviceコマンドと似ている。
| Unitコマンド | 意味 |
|---|---|
| start | Unitを開始する。 |
| stop | Unitを停止する。 |
| reload | Unitに対して設定ファイルの再読み込みを促す。 （対象のUnitがreload動作に対応している必要がある） |
| restart | 起動中のUnitを停止後、起動（stop -> start）する。 対象のUnitが停止中である場合、起動操作のみ実施する。 |
| try-restart | 起動中のUnitを停止後、起動する。 対象Unitが停止中である場合、起動操作は実施しない。 （Unit起動中のみ再起動する） |
| reload-or-restart | 対象のUnitがreloadに対応している場合、reloadする。 reloadに対応していない場合はrestart（stop -> start）する。 対象Unitが停止中である場合、起動操作のみ実施する。 |
| reload-or-try-restart | reload-or-restartと同じだが、対象Unitが停止中の場合、起動操作は行わない。 |
| kill | 対象のUnitに対してシグナルを送信する。 デフォルトで送信されるシグナルはSIGTERM（killコマンドと同じ）である。 --signal=[シグナル名]オプションで送信するシグナルを変更できる。 |
なお、従来のserviceコマンドも引き続き利用可能だ。
service [Unit名] [Unitコマンド]
systemctlとserviceの違い
取り扱う事ができるUnitタイプが異なる。systemctlは全てのUnitタイプを扱えるのに対して、serviceはserviceタイプのUnitしか取り扱う事ができない。
また、systemctlを利用する場合は、拡張子を含めたUnit名（*.mount、*.socket等）を指定する必要がある（※）が、serviceはserviceタイプのUnitのみ取り扱うため、Unitの拡張子は指定できない。（serviceコマンド内で自動的に.serviceが付与される）
※ ただし、serviceタイプのUnitは拡張子を省略可能だ。そのため、systemctl start/stop httpdのように指定できる。
システムブート時のサービスの起動設定
起動ON / OFFの設定
システムブート時のサービスの起動設定はsystemctlコマンドとchkconfigコマンドで設定可能だ。
systemctl enable/disable [Unit名]
$ sudo systemctl enable httpd ln -s '/usr/lib/systemd/system/httpd.service' '/etc/systemd/system/multi-user.target.wants/httpd.service' $ sudo systemctl disable httpd rm '/etc/systemd/system/multi-user.target.wants/httpd.service'
systemctlは起動設定を行うtarget（このtargetの設定方法は次項参照）のwantsディレクトリに対して対象のUnitへのシンボリックリンクを作成/削除する（依存性を設定する）。これは従来の/etc/init.d/rc[runlevel].d/に対するシンボリックリンク作成/削除に相当する処理と言えるだろう。
なお、従来のchkconfigも利用可能となっている。
chkconfig [Unit名] on/off
$ sudo chkconfig httpd on 情報:'systemctl enable httpd.service'へ転送しています。 ln -s '/usr/lib/systemd/system/httpd.service' '/etc/systemd/system/multi-user.target.wants/httpd.service' $sudo chkconfig httpd off 情報:'systemctl disable httpd.service'へ転送しています。 rm '/etc/systemd/system/multi-user.target.wants/httpd.service'
chkconfigをを実行した場合、その内容はsystemctlに転送され、systemctlと同様の処理が行われる。
また、--levelオプションは指定可能であるものの、その指定は無視（設定方法は次項参照）される。
起動設定するtargetの指定方法（起動設定するランレベルの指定方法）
前回の記事でも説明させていただいたが、Systemdにランレベルは存在しない。代わりに従来のランレベルに相当するtargetタイプのUnitが用意されており、これらUnitへの依存性を定義することでON / OFFを設定する。初期状態では以下のtargetが用意されている。
| target名 | 内容 | 従来のランレベル (RedHat) |
|---|---|---|
| poweroff.target | システム停止 | 0 |
| rescue.target | シングルユーザモード | 1 |
| multi-user.target | マルチユーザモード （コンソールログイン） | 3 |
| graphical.target | マルチユーザ＋GUI | 5 |
| reboot.target | 再起動 | 6 |
| emergency.target | 緊急シェル rescue.targetよりも起動対象が少ない ルートファイルシステムですら マウントできない場合などに利用 | 無し |
systemctlやchkconfigコマンドが起動設定を行うtargetはUnitファイル内の[Install]セクションに在るWantedByで設定する。（systemctlのオプションやchkconfig --levelは利用しない）
$ cat /usr/lib/systemd/system/httpd.service
[Unit]
Description=The Apache HTTP Server
After=network.target remote-fs.target nss-lookup.target
[Service]
Type=notify
EnvironmentFile=/etc/sysconfig/httpd
ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND
ExecReload=/usr/sbin/httpd $OPTIONS -k graceful
ExecStop=/bin/kill -WINCH ${MAINPID}
KillSignal=SIGCONT
PrivateTmp=true
[Install]
WantedBy=multi-user.target
上記のUnitファイルは16行目にWantedBy=multi-user.targetが指定されている。この場合、systemctlやchkconfigコマンドはmulti-user.targetを対象として起動設定を行う。（multi-user.targetは従来のランレベル3に相当する）
WantedByのUnitを変更することで起動設定を行うtargetを変更できる。（Unitファイルを編集する場合は、/usr/lib/systemd/system配下を直接編集するのでは無く、/etc/systemd/system配下にコピーのうえ編集すること）
Unitのマスキング（無効化）
Systemdではmaskという操作を実行できる。mask操作を行う事で、サービスの起動自体不可能になる。systemctl(1)では、これはdisableの強化版だとの説明されている。
systemctl mask/unmask [Unit名]
$ sudo systemctl mask httpd ln -s '/dev/null' '/etc/systemd/system/httpd.service' $ sudo systemctl unmask httpd rm '/etc/systemd/system/httpd.service'
実行結果を見ると分かるように、/etc/systemd/system上のUnitファイルに/dev/nullへのシンボリックリンクが張られている。前回の記事でも紹介させていただいたが、Unitファイルは/etc/systemd/system⇒/usr/lib/systemd/systemの順に参照される。優先度の高い/etc/systemd/system上に/dev/nullへのシンボリックリンクを配置することで、対象Unitへの操作を無効化している事が分かる。
| ディレクトリ | 設定内容 |
|---|---|
| /usr/lib/systemd/system | インストール時の初期設定 当ディレクトリ内のUnitは編集しない |
| /etc/systemd/system | ユーザによる個別設定 デフォルトの設定を変更する場合は、当ディレクトリにUnitファイルをコピーして編集する （Systemdは当ディレクトリのUnitを優先する） |
ちなみに、/etc/systemd/system配下に既にUnit定義ファイルが存在する場合、マスク操作は実行できない。（実行できたらユーザ個別設定が上書きされてしまう）
$ file /etc/systemd/system/httpd.service /etc/systemd/system/httpd.service: ASCII text $ #既にUnit定義ファイルが存在するからmask化失敗 $ sudo systemctl mask httpd.service Failed to issue method call: File exists
起動ON / OFF設定の確認方法
システムブート時の起動ON/OFF設定はsystemctl is-enabledコマンドで確認できる。
systemctl is-enabled [Unit名]
$ systemctl is-enabled httpd.service enabled
上記の例では”enabled”となっているため、httpd.serviceはシステムブート時に有効化される。
実行結果には”enabled”の他に以下のような種類がある。
| 結果 | 内容 |
|---|---|
| enabled | 有効化されている。 UnitファイルのWantedBy句に指定されたtargetと同時に起動する。 |
| disabled | 無効化されている。 UnitファイルのWantedBy句に指定されたtargetと同時起動しない。 |
| masked | マスクされている。 自動起動対象とならないし、手動起動もできない。 |
| linked | リンクされている。 Unitファイルは異なるUnitファイルへのシンボリックリンクとなっている。 （Systemdはリンク先の別Unitファイルの設定を読み取る） |
| static | 有効化／無効化の対象外。 UnitファイルにWantedBy句がそもそも指定されていない。 |
ランレベルを取り扱う
従来のランレベル関連の操作に相当する操作を説明する。
現在稼働するtarget（ランレベル）の変更
以下のコマンドで現在稼働するtarget（従来のランレベル相当）を変更できる。なお、対象とするUnitは「起動ON / OFFの設定」に記載したUnitを指定する。
systemctl isolate [対象Target Unit名]
デフォルトの起動target（デフォルトのランレベル）の変更
以下のコマンドでデフォルトで起動するtarget（デフォルトのランレベル相当）を変更できる。
systemctl set-default [対象Target Unit名]
$ #デフォルトtargetをgraphical.targetに設定 $ #従来の「デフォルトランレベル=5設定」に相当 $ sudo systemctl set-default graphical.target rm '/etc/systemd/system/default.target' ln -s '/usr/lib/systemd/system/graphical.target' '/etc/systemd/system/default.target'
実行結果から分かるように/etc/systemd/system/deafult.targetに/usr/lib/systemd/graphical.targetへのシンボリックリンクを作成していることが分かる。default.targetはSystemdによるブートの基点となるUnitである。Systemdはシステムブート時にdefault.targetを探索し、default.targetの設定を元にブートを操作を実行する。従来のランレベル切り替えに相当する操作は、このdefault.targetのリンク先を変更することで実現されている。
Unitの状態を把握する
次に個々のUnitの状態を確認するためのコマンド群を見ていこう。
起動中のUnit一覧を取得
以下のコマンドを実行することで、有効化されているUnit一覧を取得できる。
systemctl または systemctl list-units
$ #一部抜粋 $ #現在有効化されているUnitの一覧 $ systemctl list-units UNIT LOAD ACTIVE SUB DESCRIPTION proc-sys-fs-binfmt_misc.automount loaded active waiting Arbitrary Executable File Formats File System Automount Poi sys-subsystem-net-devices-enp0s3.device loaded active plugged PRO/1000 MT Desktop Adapter sys-subsystem-net-devices-enp0s8.device loaded active plugged PRO/1000 MT Desktop Adapter -.mount loaded active mounted / boot.mount loaded active mounted /boot dev-hugepages.mount loaded active mounted Huge Pages File System dev-mqueue.mount loaded active mounted POSIX Message Queue File System auditd.service loaded active running Security Auditing Service avahi-daemon.service loaded active running Avahi mDNS/DNS-SD Stack ...
また、--typeオプションを利用することでUnitタイプを指定できる。
$ #一部抜粋 $ #現在有効化されており、かつserviceタイプのUnit一覧 $ systemctl list-units --type=service UNIT LOAD ACTIVE SUB DESCRIPTION auditd.service loaded active running Security Auditing Service avahi-daemon.service loaded active running Avahi mDNS/DNS-SD Stack crond.service loaded active running Command Scheduler dbus.service loaded active running D-Bus System Message Bus firewalld.service loaded active running firewalld - dynamic firewall daemon getty@tty1.service loaded active running Getty on tty1 ...
表示項目のうちUNITはUnit名、LOADはSystemdへの設定読み込み状況、ACTIVE、SUBがUnitの実行状態、DESCRIPTIONがUnitの概要を表している。
起動対象となっているにも関わらず、起動に失敗している場合はACTIVEやSUBがfailedといった表記となる。
Systemdが認識しているUnit一覧の表示
以下のコマンドで確認できる。
systemctl list-unit-files
$ #一部抜粋 $ #Systemdが認識しているUnitの一覧 $ systemctl list-unit-files UNIT FILE STATE proc-sys-fs-binfmt_misc.automount static dev-hugepages.mount static dev-mqueue.mount static proc-sys-fs-binfmt_misc.mount static sys-fs-fuse-connections.mount static sys-kernel-config.mount static sys-kernel-debug.mount static tmp.mount disabled brandbot.path disabled systemd-ask-password-console.path static systemd-ask-password-plymouth.path static ...
STATE列はUNITの起動設定を表している。表示されている内容は「起動ON / OFFの確認方法」に記載した表の内容と同様である。
Unitの現在の状態を確認
以下のコマンドでUnitの状態を確認できる。
systemctl status [Unit名]
$ #apache起動
$ sudo systemctl start httpd.service
$ #apacheの状態確認 -起動状態-
$ systemctl status httpd.service
httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; linked)
Active: active (running) since 土 2014-07-19 23:39:27 JST; 1min 34s ago
Main PID: 2641 (httpd)
Status: "Total requests: 0; Current requests/sec: 0; Current traffic: 0 B/sec"
CGroup: /system.slice/httpd.service
├─2641 /usr/sbin/httpd -DFOREGROUND
├─2642 /usr/sbin/httpd -DFOREGROUND
├─2643 /usr/sbin/httpd -DFOREGROUND
├─2644 /usr/sbin/httpd -DFOREGROUND
├─2645 /usr/sbin/httpd -DFOREGROUND
└─2646 /usr/sbin/httpd -DFOREGROUND
$ #apache停止
$ sudo systemctl stop httpd.service
$ #apacheの状態確認 -停止状態-
$ systemctl status httpd.service
httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; linked)
Active: inactive (dead)
7月 19 23:39:27 localhost.localdomain systemd[1]: Starting The Apache HTTP Server...
7月 19 23:39:27 localhost.localdomain httpd[2641]: AH00558: httpd: Could not reliably determine the server's fully qualified domain...essage
7月 19 23:39:27 localhost.localdomain systemd[1]: Started The Apache HTTP Server.
7月 19 23:44:49 localhost.localdomain systemd[1]: Stopping The Apache HTTP Server...
7月 19 23:44:50 localhost.localdomain systemd[1]: Stopped The Apache HTTP Server.
Hint: Some lines were ellipsized, use -l to show in full.
調査対象Unitの現在の状況（上記例ではactive）や、対象Unitを元としたプロセス一覧などを把握できる。
UNITの依存関係を把握する
Unit間の依存関係は個々のUnitファイルに定義されている。しかし、Unitファイルは多数存在し、全体の依存関係を把握するのは困難だ。以下のコマンドで対象のUnitの依存関係をツリー構造で表示できる。
systemctl list-dependencies [Unit名]
$ #一部抜粋 $ #apahceが依存しているUnit一覧を表示 $ systemctl list-dependencies httpd.service httpd.service ├─system.slice └─basic.target ├─firewalld.service ├─microcode.service ├─rhel-autorelabel-mark.service ├─rhel-autorelabel.service ├─rhel-configure.service ├─rhel-dmesg.service ├─rhel-loadmodules.service ├─paths.target ├─slices.target │ ├─-.slice │ └─system.slice ├─sockets.target │ ├─avahi-daemon.socket │ ├─dbus.socket ...
また、以下のオプションも利用可能だ。
| オプション | 意味 |
|---|---|
| --reverse | 対象Unitに依存しているUnit一覧を表示する。例えば systemctl --reverse list-dependencies sysinit.target は、sysinit.targetが起動対象とならない限り、 起動できないUnitを一覧表示する。 |
| --after | 対象Unitよりも先に起動されるべきUnit一覧を表示する。例えば systemctl --after list-dependencies sysinit.target は、systeinit.targetよりも先に起動されるべきUnitを一覧表示する。 ※ 結果に表示されるUnitはあくまで起動順を指しており、 必ずしも同時起動の対象となるUnitではない |
| --before | 対象Unitよりも後に起動されるべきUnit一覧を表示する。例えば systemctl --reverse list-dependencies sysinit.target は、sysinit.targetが起動した後に起動されるべきUnitを一覧表示する。 |
なお、Systemdでは、暗黙的に起動順や依存関係が設定されるtargetが存在する（特殊なUnitはマニュアルsystemd.special(7)を参照）。list-dependenciesはこういったUnitファイルに直接記載されない依存・起動順の表示が行えるため、依存・起動順の確認はファイルの中身を直接見るよりも当コマンドで利用した方が確実だ。
Unitファイルを編集し、Systemdに反映する
Unitファイルを編集する
様々なシステム管理コマンドを列挙したが、Unitファイルを編集することで設定を変更することができる。
/etc/systemd/systemディレクトリ配下に/usr/lib/systemd/system配下のUnitファイルをコピーしてからUnitファイルを編集しよう。/usr/lib/systemd/system配下のUnitファイルはUnitインストール時の初期設定を保持するためのディレクトリであり、このディレクトリ配下のUnitは編集してはいけない。
Unitファイルの変更をSystemdに通知する
以下のコマンドを実行する事で、Unitファイルの変更をSystemdに通知することができる。
このコマンドを実行しないと変更内容がSystemdに反映されない。（Unitファイルの直接編集ではなく、systemctlコマンドを利用して設定変更した場合は実行不要である）
systemctl daemon-reload
サーバシャットダウン・再起動・サスペンドを実施する
systemctlコマンドはサーバのシャットダウンや再起動を実施できる。（従来のshutdownコマンドも引き続き利用可能）
systemctl halt/poweroff/reboot/suspend/hibernate/hybrid-sleep
suspendは”suspend to ram”、hibernateは”suspend to disk(swap)”、hybrid-sleepは”suspend to both”と思われる。
journalctlを利用してSystemdログを参照する
ここからはSystemctl独自のログ機構であるSystemd journalを利用したログの照会方法を解説していく。
Systemd journalとは
Systemdは独自のログ機構であるSystemd journalを保持している。RHEL7/CentOS7はFedora19をベースとしており、syslog（rsyslogd）とSystemd Journalが相乗りした状態となっているが、Fedora20からはsyslogが非デフォルトとなり、基本的にSystemd journalを利用する方針となった。この点を踏まえるとRHEL/CentOSのログ機構は将来的にはSystemd journalに一本化される可能性が高い。
Systemd journalではSystemdが記録した様々なログをjournalctlコマンドを通して照会する。Systemdはシステムの起動〜サービスの管理を行うため、ありとあらゆるシステムのログを収集できる立場にあるが、journalctlでは、こららのログを必要に応じて抽出して閲覧することができるのだ。
当項では、journalctlの基本的な利用方法と、Systemdが取得するログの永続化方法について解説する。（RHEL7/CentOS7のSystemdのログはデフォルトではtmpfs上に格納されており、システム再起動時にログが消失してしまう）
journalctlの利用方法
パラメータ無しでjournalctlを実行すると古いログから順に全ログが出力される。
journalctl
$ #一部抜粋 $ #全ログの表示 $ sudo journalctl -- Logs begin at 日 2014-07-20 20:23:11 JST, end at 日 2014-07-20 21:02:46 JST. -- 7月 20 20:23:11 localhost.localdomain systemd-journal[80]: Runtime journal is using 4.0M (max 24.5M, leaving 36.7M of free 241.1M, current li 7月 20 20:23:11 localhost.localdomain systemd-journal[80]: Runtime journal is using 4.0M (max 24.5M, leaving 36.7M of free 241.1M, current li 7月 20 20:23:11 localhost.localdomain kernel: Initializing cgroup subsys cpuset 7月 20 20:23:11 localhost.localdomain kernel: Initializing cgroup subsys cpu 7月 20 20:23:11 localhost.localdomain kernel: Initializing cgroup subsys cpuacct 7月 20 20:23:11 localhost.localdomain kernel: Linux version 3.10.0-123.el7.x86_64 (builder@kbuilder.dev.centos.org) (gcc version 4.8.2 201401 7月 20 20:23:11 localhost.localdomain kernel: Command line: BOOT_IMAGE=/vmlinuz-3.10.0-123.el7.x86_64 root=UUID=3e7830d3-0d7c-4f1d-9b6b-2ca10 7月 20 20:23:11 localhost.localdomain kernel: e820: BIOS-provided physical RAM map: ...
ログを見ると分かるが、システム起動時のカーネルログや個々のUnitに関するログが混在した状態で表示される。以下に記載するオプションを利用して、表示対象を抜粋することができる。（オプション一覧と詳細はjournalctlのmanページを参照）
| オプション | 書式 | 意味 |
|---|---|---|
| -u --unit | jorunalctl -u [Unit名] journalctl --unit=[Unit名] | 指定したUnitに関するログのみ抜粋する。 |
| _PID | jounalctl _PID=[プロセスID] | 指定したプロセスIDを持つプロセスのログのみ抜粋する。 |
| -p --priority | jounalctl -p [Priority] jounalctl --priority=[Priority] | 指定したプライオリティに関するログのみ抜粋する。 指定できるプライオリティはsyslogと同じ。 (ただし、syslogでいう"warn"は"warning"と表記する) |
| -b | journalctl -b jounalctl -b -[数値] | 起動時からの全メッセージを表示。 [数値]に"0"（デフォルト）を指定した場合、 現在の起動以降のログを表示する。 "1"の場合は前回起動の関するログを表示する。 "2"は前々回起動・・・という形式。 |
| -f | journalctl -f | 新しいログを表示し、ログが追加される度に追跡表示する。 tail -fと同じ使い方ができる。 |
| -n --line | journalctl -n [行数] journalctl --line=[行数] | 指定した末尾の行数を表示する。 -fはデフォルト10行なので、組み合わせて使うと良い。 （よくあるtailの使い方） |
| -o --output | journalctl -o [Format] journalctl --output=[Format] | 指定したフォーマットでログを出力する。 指定できるフォーマットはman journalctl(1)を参照。 json形式でログ出力もできる。 |
| -k --dmesg | journalctl -k journalctl --dmesg | カーネルログのみ抜粋する。 dmesgと同様の表示。 |
journalログを永続化する
Systemd journalのログはデフォルト設定の場合/run/log/journal配下に保存されている。/runディレクトリはtmpfsとなっているため、システムを再起動した場合ログが消失してしまう。これを防ぐ（journalログを永続化する）方法を確認していこう。
jorunalログの設定
Systemd journalの設定は/etc/systemd/journald.confで行う。デフォルトの状態では、以下のように全ての設定がコメントアウトされた状態となっている。
$ cat /etc/systemd/journald.conf # This file is part of systemd. # # systemd is free software; you can redistribute it and/or modify it # under the terms of the GNU Lesser General Public License as published by # the Free Software Foundation; either version 2.1 of the License, or # (at your option) any later version. # # See journald.conf(5) for details [Journal] #Storage=auto #Compress=yes #Seal=yes #SplitMode=login #SyncIntervalSec=5m #RateLimitInterval=30s #RateLimitBurst=1000 #SystemMaxUse= #SystemKeepFree= #SystemMaxFileSize= #RuntimeMaxUse= #RuntimeKeepFree= #RuntimeMaxFileSize= #MaxRetentionSec= #MaxFileSec=1month #ForwardToSyslog=yes #ForwardToKMsg=no #ForwardToConsole=no #TTYPath=/dev/console #MaxLevelStore=debug #MaxLevelSyslog=debug #MaxLevelKMsg=notice #MaxLevelConsole=info
ログの永続化に関する設定項目は12行目に表示されているStorageである。Storageは主に以下の項目を設定できる。
| 設定値 | 内容 |
|---|---|
| auto | デフォルト設定。以下のルールでログの格納先を決定する。 /var/log/journalディレクトリが存在する場合、この配下にログを記録する。（ディスク保存） /var/log/journalディレクトリが存在しない場合は/run/log/journal配下にログを記録する。（メモリ保存） |
| volatile | ログはメモリ上(/run/log/journal配下）に格納される。 システム再起動後にログを持ち越すことはできない。 |
| persistent | ログはディスク上（/var/log/journal配下）に格納される。 /var/log/journalディレクトリが存在しない場合でも、systemdは自動的にディレクトリを作成し、その配下にログを記録する。 |
ログの永続化を行う場合に設定できる値はautoかpersistentとなる。persistentを指定した場合、ログの格納先ディレクトリをSystemdが自動で作成するため、特に追加の設定は不要であるが、autoを設定する場合は、/var/log/journalディレクトリを新規作成することでログを永続化できる。
まとめ
駆け足でSystemdによるシステム管理のコマンドを紹介させていただいた。Systemd理解への一助となれば幸いである。
今回、Systemdを調査を通してSystemdの適用範囲が非常に広い事を改めて思い知った次第だ。Systemdはシステムの起動から管理まで至るところに登場し、様々な操作を行うことができる。”システムデーモン”というネーミングは、システムそのものを管理するデーモンという意味で正に的を得ているのではないだろうか。今後RHEL7/CentOS7の導入が進んだ場合、Systemdの理解は必須となると思われる。init/Upstartをはじめ、様々な既存の仕組みを置き換えるSystemdを理解しなければまともなサーバ管理は行えないだろう。
また、Systemdではmanが非常に充実している。例えばSystemd本体はsystemd(1) 、systemctlはsystemctl(1)、Unitファイルはsystemd.unit(5)といった具合だ。これらのSystemd関連のmanはsystemd.index(7)にまとめられている。Systemdでつまづいた際は、落ち着いてmanを参照すると良いだろう。