9.10. Systemd の利用と設定

9.10.1. 基本的な設定

/etc/systemd/system.conf ファイルには、基本的な systemd 動作を制御するための設定オプション項目があります。 デフォルトのファイルは、各項目のデフォルト値が示された上でそれがコメントアウトされています。 このファイルでは基本的なジャーナル設定やログレベルを設定する必要があります。 各オプションの詳細については man ページ systemd-system.conf(5) を参照してください。

9.10.2. ブート時の画面クリアの防止

通常 systemd はブート処理の最後に画面をクリアします。 必要ならばこの動きを以下のようにして変更することができます。

mkdir -pv /etc/systemd/system/getty@tty1.service.d

cat > /etc/systemd/system/getty@tty1.service.d/noclear.conf << EOF
[Service]
TTYVTDisallocate=no
EOF

ブートメッセージは、root ユーザーになってコマンド journalctl -b を実行することで、常に表示しておくこともできます。

9.10.3. /tmp の tmpfs としての生成抑止

デフォルトでは /tmp は tmpfs として生成されます。 これが適当ではないならば、以下のコマンドによりオーバーライドすることができます。

ln -sfv /dev/null /etc/systemd/system/tmp.mount

それとは別に /tmp を別パーティションとする場合は、/etc/fstab にそのパーティションを指定します。

9.10.4. 自動的なファイル生成、削除の設定

ファイルやディレクトリを生成、削除するサービスがいくつかあります。

システム用設定ファイルは /usr/lib/tmpfiles.d/*.conf です。 ローカル用設定ファイルは /etc/tmpfiles.d/*.conf に置きます。 /etc/tmpfiles.d にあるファイルは /usr/lib/tmpfiles.d にある同名ファイルをオーバーライドします。 ファイル書式の詳細については man ページ tmpfiles.d(5) を参照してください。

/usr/lib/tmpfiles.d/*.conf ファイルの文法はやっかいなものです。 例えば /tmp ディレクトリ内のファイルを消去するためのデフォルト設定は /usr/lib/tmpfiles.d/tmp.conf ファイルに以下のように記述されます。

q /tmp 1777 root root 10d

型を表わす q はクォータを用いたサブボリュームを生成するものとして説明されています。 ただこれが適用できるのは btrfs ファイルシステムのみです。 この型は v を参照し、次に d（ディレクトリ）を参照します。 指定されたディレクトリが存在しない場合はそれが生成されて、パーミッションと所有者が指定されたものに設定されます。 時間指定が行われた場合、そのディレクトリ内のファイルは、それに応じて削除されます。

デフォルトパラーメーターを必要としない場合は、設定ファイルを /etc/tmpfiles.d にコピーして必要な設定を行っておきます。 例えば以下です。

mkdir -p /etc/tmpfiles.d
cp /usr/lib/tmpfiles.d/tmp.conf /etc/tmpfiles.d

9.10.5. デフォルトのサービス動作のオーバーライド

ユニットパラメーターをオーバーライドするには /etc/systemd/system ディレクトリを生成して設定ファイルを作成します。 例えば以下のとおりです。

mkdir -pv /etc/systemd/system/foobar.service.d

cat > /etc/systemd/system/foobar.service.d/foobar.conf << EOF
[Service]
Restart=always
RestartSec=30
EOF

詳しくは man ページ systemd.unit(5) を参照してください。 設定ファイルを作成したら systemctl daemon-reload と systemctl restart foobar を実行します。 これによりサービスの設定内容が反映されます。

9.10.6. ブートシーケンスのデバッグ

SysVinit や BSD スタイルの起動システムにおいては単純なシェルスクリプトが用いられていますが、 systemd ではさまざまな形式の起動ファイル (あるいはユニット) を統一化するフォーマットが用いられています。 systemctl コマンドがユニットファイルの有効/無効、状態制御/参照を行います。 以下に示すものがよく用いられます。

9.10.7. Systemd ジャーナル関連の操作

systemd により起動したシステムのシステムログは、従来の unix syslog デーモンとは異なり、デフォルトで systemd-journald により扱われます。 必要に応じて標準的な syslog デーモンを追加することも可能で、両者を併用することもできます。 systemd-journald プログラムはジャーナル項目を保存しますが、それはテキストログファイルではなく、バイナリフォーマットファイルです。 そのファイル内容を確認するために journalctl コマンドが提供されています。 以下に示すものがよく用いられます。

9.10.8. コアダンプ関連の操作

クラッシュしたプログラムをデバッグするのに、コアダンプというものが重宝します。 特にデーモンプロセスがクラッシュした場合です。 systemd によるブートシステムにおいて、コアダンプは systemd-coredump が取り扱います。 このプログラムはジャーナル内にコアダンプのログを出力し、コアダンプそのものは /var/lib/systemd/coredump に保存します。 コアダンプを取り出して処理するために coredumpctl というツールが提供されています。 よく利用されるコマンド例を以下に示します。

コアダンプはディスク容量を大量に消費することがあります。 /etc/systemd/coredump.conf.d に設定ファイルを生成して、 コアダンプに利用するディスク容量の最大を制御することができます。 たとえば以下のとおりです。

mkdir -pv /etc/systemd/coredump.conf.d

cat > /etc/systemd/coredump.conf.d/maxuse.conf << EOF
[Coredump]
MaxUse=5G
EOF

詳細は systemd-coredump(8), coredumpctl(1), coredump.conf.d(5) の各 man ページを参照してください。

9.10.9. 稼動し続けるプロセス

systemd-230 より取り入れられた機能として、ユーザープロセスは、たとえ nohup が用いられたり、あるいは daemon() や setsid() が利用されたプロセスであっても、ユーザーセッションが終了するとともに終了します。 この機能変更は、従来からの柔軟な実装を厳格なものとする意図で行われたものです。 したがって稼動し続けるプロセスが利用されていると (例えば screen や tmux など)、この機能変更が問題を引き起こすことになるかもしれません。 つまりユーザーセッションが終了した後にもプロセスをアクティブにしておくことが必要になります。 ユーザーセッション終了後にプロセスを継続させる方法として、以下の三つの方法があります。