Difference between revisions of "Systemd (日本語)"

From ArchWiki
Jump to: navigation, search
m
m (ブラックリスト)
Line 163: Line 163:
  
 
==== ブラックリスト ====
 
==== ブラックリスト ====
モジュールのブラックリストは、{{Pkg|kmod}} によって扱われるので、{{Pkg|initscripts}} の時と同じ方法で動作します。詳細は [[Kernel_modules#Blacklisting|Module Blacklisting]] にあります。
+
モジュールのブラックリストは、{{Pkg|kmod}} によって扱われるので、{{Pkg|initscripts}} の時と同じ方法で動作します。詳細は [[Kernel modules (日本語)#ブラックリスト|Module Blacklisting]] にあります。
  
 
=== ファイルシステムをマウントする ===
 
=== ファイルシステムをマウントする ===

Revision as of 16:07, 31 December 2012

Template:Article summary start Template:Article summary text Template:Article summary heading Template:Article summary wiki Template:Article summary wiki Template:Article summary wiki Template:Article summary wiki Template:Article summary wiki Template:Article summary end project web page より:

systemd は SysV や LSB init スクリプトと互換性のある、Linux 用のシステム・サービスマネージャです。systemd はサービスの起動を積極的に並行化します。また、サービス起動時にソケットと D-Bus を有効化し、必要なサービスの開始と Linux の cgroups によるプロセス管理ができます。システム状態のスナップショット作成と復元、(自動)マウントポイントの維持、依存に基づいたサービスのコントロールをサポートします。systemd は sysvinit の代替として動きます。

Note: systemd が Arch に採用された理由については、フォーラムへのこの投稿をご覧ください。

詳しくは、Wikipedia の記事本家のホームページもどうぞ。

Contents

移行前に考慮すべきこと

  • 本家のホームページで、systemd についてざっと読んでください。
  • systemd の journal システムは、syslog の機能を提供し置き換えます。ただしこれらは共存できます。下の journal についてのセクションを読んでください。
  • systemd が cronacpidxinetd の機能を代替しようとする計画がありますが、今はまだ伝統的なデーモンを使い続けることができます。
  • インタラクティブな initscript は sytemd では動きません。特に、起動時に netcfg-menu を使うことはできません

インストール

Note: 2012-10-13 からの新しいインストールメディアでは systemdsystemd-sysvcompat が両方デフォルトでインストールされます。
Note: VPS で Arch Linux を実行している場合、このページを見て下さい。

以下のセクションは systemd にまだ以降していない sysvinitinitscripts による Arch Linux のためのインストールです。

  1. systemd をインストールして kernel line に次を加えます: init=/usr/lib/systemd/systemd
  2. 完了したら、必要なサービスを systemctl enable <service_name> を使って有効にできます (大雑把に言うと DAEMONS 行に違う名前で追加するのと同じです)。
  3. システムを再起動し、systemd がアクティブになっていることを次のコマンドで確認します: cat /proc/1/commsystemd の文字が返ってくるはずです。
  4. systemd であなたのホストネームを設定します: hostnamectl set-hostname myhostname
  5. initscriptssysvinit をシステムから削除し systemd-sysvcompat をインストールしてください。
  6. もう必要なくなった init=/usr/lib/systemd/systemd パラメータを削除してください。systemd-sysvcompat がデフォルトの init になります。

追加情報

  • カーネルパラメータに quiet を設定している場合、それを削除することで、起動中に何が起こっているかわかりやすくなります。
  • systemd を使うにあたってユーザーにグループ (optical, audio, scanner, etc.) を設定しなくてはいけない場合はほとんどありません。グループは機能を破壊することさえあります。例えば、audio グループは高速ユーザー切り替えやアプリケーションのソフトウェアミキシングを無効にします。全ての PAM ログインは logind セッションを提供します。オーディオ/ビデオデバイスに POSIX ACL を通して権限を与えたり、udisks を使ってリムーバルディスクのマウントなどの操作を行います。
Note: If you use startx -- vt7 , the logind session doesn't apply to your X environment, and you will NEED to keep the groups.
  • initscripts パッケージを消去すると rc.conf の互換性がなくなります。デーモンやネットワークの設定をそこで行なっていた場合、systemd に移行されないので注意してください。2つのシステムを共存させる方法について詳しくは initscripts のエミュレーションのセクションを見て下さい。
  • fstab で LVM デバイスをマウントしている場合、システムはそれらを待ち、タイムアウトします。タイムアウトするのを待ってから、緊急コンソールで root パスワードを入力してください。その後 systemctl enable lvm と入力することで systemd で lvm が有効になります。再起動後、lvm デバイスがマウントできるようになっているはずです。

ネイティブの設定

Note: これらのファイルを作る必要があります。全てのファイルのパーティションは 644 で所有者は root:root である必要があります。

ホストネーム

ホストネームは /etc/hostname で設定します。このファイルにシステムのドメインを含めてはいけません。ホストネームを設定するには:

# hostnamectl set-hostname myhostname

詳しくは man 5 hostnameman 1 hostnamectl を見て下さい。

ファイルの設定サンプル:

/etc/hostname
myhostname

Locale

デフォルトのシステムロケールは /etc/locale.conf で設定します。デフォルトロケールをセットするには:

# localectl set-locale LANG="de_DE.utf8"
Note: デフォルトロケールを設定する前に、/etc/locale.gen で利用するロケールをアンコメントして locale-gen を root で実行してロケールを有効にしておく必要があります。localectl でセットするロケールは /etc/locale.genアンコメントされたロケールでなければなりません。

詳しくは man 1 localectlman 5 locale.conf を見て下さい。

ファイルの設定サンプル:

/etc/locale.conf
LANG=en_US.utf8

仮想端末

仮想端末 (キーボッドマップ、コンソールフォント、コンソールマップ) の設定は /etc/vconsole.conf です:

/etc/vconsole.conf
KEYMAP=us
FONT=lat9w-16
FONT_MAP=8859-1_to_uni
Note: systemd-194 現在、KEYMAP=FONT= が空だったり設定されていない場合、ビルトインの kernel フォントと us キーマップが使われます。

キーボッドマップ(キーマップ)を設定する別の方法は:

# localectl set-keymap de

この方法なら X11 でも同じキーマップを使うように設定されます。

詳細は man 1 localectlman 5 vconsole.conf を見て下さい。

タイムゾーン

タイムゾーンは適切な /etc/localtime シンボリックリンクを作ることで設定します。リンク先は /usr/share/zoneinfo/ 下のゾーン情報ファイルです。自動で行うには:

# timedatectl set-timezone Asia/Tokyo

詳しくは man 1 timedatectl, man 5 localtime, man 7 archlinux を見て下さい。

または、あなた自身でシンボリックリンクを作って下さい:

# ln -sf ../usr/share/zoneinfo/Asia/Tokyo /etc/localtime

古い設定ファイル /etc/timezone がある場合、削除しても問題ありません。

ハードウェアクロック

Systemd はデフォルトで UTC をハードウェアクロックに使います。

Tip: システム時刻をインターネット時刻やハードウェアクロックと同期するために Network Time Protocol daemon を使うことが推奨されます。

localtime をハードウェアクロックに

ハードウェアクロックで localtime を使うようにするには (するべきではありません):

# timedatectl set-local-rtc true

ハードウェアクロックを UTC に戻すには:

# timedatectl set-local-rtc false

警告したように、ハードウェアクロックを localtime に設定すると、夏時間の扱いで問題が生じます。 If the DST changes when your computer is off, your clock will be wrong on next boot (there is a lot more to it). Recent kernels set the system time from the RTC directly on boot, assuming that the RTC is in UTC. This means that if the RTC is in local time, then the system time will first be set up wrongly and then corrected shortly afterwards on every boot. This is the root of certain weird bugs (time going backwards is rarely a good thing).

One reason for allowing the RTC to be in local time is to allow dual boot with Windows (which uses localtime). However, Windows is able to deal with the RTC being in UTC with a simple registry fix. There, it is recommended that Windows are changed to use UTC, rather than Linux to use localtime. If you make Windows use UTC, also remember to disable the "Internet Time Update" Windows feature, so that Windows don't mess with the hardware clock, trying to sync it with internet time. You should instead leave touching the RTC and syncing it to internet time to Linux, by enabling an NTP daemon, as suggested previously.

  • 詳しくは Time を見て下さい。

カーネルモジュール

現在、すべての必要なカーネルモジュールは udev によって自動でロードされます。従って、サポート外のカーネルモジュールを使おうとしない限り、設定ファイルにモジュールをロードするように書く必要はありません。しかし、ブートプロセスでモジュールをロードしたい場合や、コンピュータを正しく機能させるためにモジュールをブラックリストに加える必要があるかもしれません。

起動時にモジュールをロード

/etc/modules-load.d/ 下のファイルに、ブート時に読み込むカーネルモジュールを設定します。それぞれの設定ファイルは /etc/modules-load.d/<program>.conf という名前です。設定ファイルには単純にロードすべきカーネルモジュールを一行毎に並べます。空の行や、スペース以外の最初の文字が #; の行は無視されます。

/etc/modules-load.d/virtio-net.conf
# Load virtio-net.ko at boot
virtio-net

詳しくは man 5 modules-load.d を見て下さい。

ブラックリスト

モジュールのブラックリストは、kmod によって扱われるので、initscripts の時と同じ方法で動作します。詳細は Module Blacklisting にあります。

ファイルシステムをマウントする

デフォルトのセットアップでは自動的に fsck が行われサービスが起動する前にファイルシステムがマウントされます。例えば、systemd は NFSSamba のようなネットワーク接続が必要なリモートファイルシステムも自動でマウントしようとします。従って /etc/fstab に明記しなくともローカル・リモードどちらのファイルシステムのマウントも問題ありません。

詳しくは man 5 systemd.mount を見て下さい。

Automount

  • If you have a large /home partition, it might be better to allow services that do not depend on /home to start while /home is checked by fsck. This can be achieved by adding the following options to the /etc/fstab entry of your /home partition:
noauto,x-systemd.automount

This will fsck and mount /home when it is first accessed, and the kernel will buffer all file access to /home until it is ready.

  • The same applies to remote filesystem mounts. If you want them to be mounted only upon access, you will need to use the noauto,x-systemd.automount parameters. In addition, you can use the x-systemd.device-timeout=# option to specify a timeout in case the network resource is not available.
  • If you have encrypted filesystems with keyfiles, you can also add the noauto parameter to the corresponding entries in /etc/crypttab. Systemd will then not open the encrypted device on boot, but instead wait until it is actually accessed and then automatically open it with the specified keyfile before mounting it. This might save a few seconds on boot if you are using an encrypted RAID device for example, because systemd doesn't have to wait for the device to become available. For example:
/etc/crypttab
data /dev/md0 /root/key noauto

LVM

If you have LVM volumes not activated via the initramfs, enable the lvm-monitoring service, which is provided by the lvm2 package:

# systemctl enable lvm-monitoring

Similarly, if you have LVM on encrypted devices mounted later during boot (e.g. from /etc/crypttab), enable the lvm-on-crypt service, which is also provided by the lvm2 package:

# systemctl enable lvm-on-crypt

ACPI 電源管理

systemd は電源関連の ACPI イベントを扱えます。/etc/systemd/logind.conf のオプションを使って設定できます:

  • HandlePowerKey: specifies which action is invoked when the power key is pressed.
  • HandleSuspendKey: specifies which action is invoked when the suspend key is pressed.
  • HandleHibernateKey: specifies which action is invoked when the hibernate key is pressed.
  • HandleLidSwitch: specifies which action is invoked when the lid is closed.

The specified action can be one of ignore, poweroff, reboot, halt, suspend, hibernate or kexec.

If these options are not configured, systemd will use its defaults: HandlePowerKey=poweroff, HandleSuspendKey=suspend, HandleHibernateKey=hibernate, and HandleLidSwitch=suspend.

On systems which run no graphical setup or only a simple window manager like i3 or awesome, this may replace the acpid daemon which is usually used to react to these ACPI events.

Note: Systemd cannot handle AC and Battery ACPI events, so if you use Laptop Mode Tools or other similar tools acpid is still required.

In the current version of systemd, the Handle options will apply throughout the system unless they are "inhibited" (temporarily turned off) by a program, such as a power manager inside a desktop environment. If these inhibits are not taken, you can end up with a situation where systemd suspends your system, then when it wakes up the other power manager suspends it again.

Warning: Currently, the power managers in the newest versions of KDE and GNOME are the only ones that issue the necessary "inhibited" commands. Until the others do, you will need to set the Handle options to ignore if you want your ACPI events to be handled by Xfce, acpid or other programs. New versions are on the way that will include this functionality.
Note: Systemd can also use other suspend backends (such as Uswsusp or TuxOnIce), in addition to the default kernel backend, in order to put the computer to sleep or hibernate.

Sleep フック

Systemd does not use pm-utils to put the machine to sleep when using systemctl suspend, systemctl hibernate or systemctl hybrid-sleep; pm-utils hooks, including any custom hooks, will not be run. However, systemd provides two similar mechanisms to run custom scripts on these events.

サスペンド/リジューム サービスファイル

Service files can be hooked into suspend.target, hibernate.target and sleep.target to execute actions before or after suspend/hibernate. Separate files should be created for user actions and root/system actions. To activate the user service files, # systemctl enable suspend@<user> && systemctl enable resume@<user>. Examples:

/etc/systemd/system/suspend@.service
[Unit]
Description=User suspend actions
Before=sleep.target

[Service]
User=%I
Type=forking
Environment=DISPLAY=:0
ExecStartPre= -/usr/bin/pkill -u %u unison ; /usr/local/bin/music.sh stop ; /usr/bin/mysql -e 'slave stop'
ExecStart=/usr/bin/sflock

[Install]
WantedBy=sleep.target
/etc/systemd/system/resume@.service
[Unit]
Description=User resume actions
After=suspend.target

[Service]
User=%I
Type=simple
ExecStartPre=/usr/local/bin/ssh-connect.sh
ExecStart=/usr/bin/mysql -e 'slave start'

[Install]
WantedBy=suspend.target

For root/system actions (activate with # systemctl enable root-suspend):

/etc/systemd/system/root-resume.service
[Unit]
Description=Local system resume actions
After=suspend.target

[Service]
Type=simple
ExecStart=/usr/bin/systemctl restart mnt-media.automount

[Install]
WantedBy=suspend.target
/etc/systemd/system/root-suspend.service
[Unit]
Description=Local system suspend actions
Before=sleep.target

[Service]
Type=simple
ExecStart=-/usr/bin/pkill sshfs

[Install]
WantedBy=sleep.target

A couple of handy hints about these service files (more in man systemd.service):

  • If Type=OneShot then you can use multiple ExecStart= lines. Otherwise only one ExecStart line is allowed. You can add more commands with either ExecStartPre or by separating commands with a semicolon (see the first example above -- note the spaces before and after the semicolon...these are required!).
  • A command prefixed with '-' will cause a non-zero exit status to be ignored and treated as a successful command.
  • The best place to find errors when troubleshooting these service files is of course with journalctl.
/usr/lib/systemd/system-sleep のフック

Systemd runs all executables in /usr/lib/systemd/system-sleep/, passing two arguments to each of them:

  • Argument 1: either pre or post, depending on whether the machine is going to sleep or waking up
  • Argument 2: suspend, hibernate or hybrid-sleep, depending on which is being invoked

In contrast to pm-utils, systemd will run these scripts concurrently and not one after another.

The output of any custom script will be logged by systemd-suspend.service, systemd-hibernate.service or systemd-hybrid-sleep.service. You can see its output in systemd's journal:

# journalctl -b -u systemd-suspend

Note that you can also use sleep.target, suspend.target, hibernate.target or hybrid-sleep.target to hook units into the sleep state logic instead of using custom scripts.

カスタムスリープスクリプトの例:

/usr/lib/systemd/system-sleep/example.sh
#!/bin/sh
case $1/$2 in
  pre/*)
    echo "Going to $2..."
    ;;
  post/*)
    echo "Waking up from $2..."
    ;;
esac

詳しくは man 7 systemd.specialman 8 systemd-sleep を見て下さい。

一時ファイル

Systemd-tmpfiles は /usr/lib/tmpfiles.d//etc/tmpfiles.d/ 下にある設定ファイルを読み、通常 /run/tmp などのディレクトリにある一時ファイル・ディレクトリの作成、内容の消去、削除などを行います。それぞれの設定ファイル名は /etc/tmpfiles.d/<program>.conf です。/usr/lib/tmpfiles.d/ に同名の設定ファイルがある場合上書きされます。

tmpfiles は一時ファイルを必要とするデーモンのサービスファイルに同梱されます。例えば Samba デーモンは /var/run/samba を一時ディレクトリとして使用するため、正しいパーミッションに設定されていることを期待します。これを表す tmpfile は以下のようになります:

/usr/lib/tmpfiles.d/samba.conf
D /var/run/samba 0755 root root

しかし、tmpfiles は起動時にファイルに値を書き込むのにも使われることがあります。例えば、/etc/rc.local を使って USB デバイスからの wakeup を無効化する echo USBE > /proc/acpi/wakeup ことは、tmpfile では以下のように書けます:

/etc/tmpfiles.d/disable-usb-wake.conf
w /proc/acpi/wakeup - - - - USBE

この場合、systemd が /etc/rc.local をサポートしていないので、tmpfiles を使う方法が推奨されるのです。

詳細は man 5 tmpfiles.d を参照。

ユニット

ユニット設定ファイルは、systemd によって管理される、サービス、ソケット、デバイス、(自動)マウントポイント、スワップパーティション(ファイル)、ターゲット、ファイルシステムのパス、タイマーについての設定をまとめたものです。設定の構文は XDG の .desktop を真似ていて、これは Microsoft Windows の .ini ファイルに影響を受けています。

詳しくは man 5 systemd.unit を参照。

initscripts から systemd への移行

initscripts のエミュレーション

伝統的な Arch の設定は initscripts パッケージによって統合させられます。systemd と initscripts がインストールされていて、systemd によってシステムが動いている時、systemd は以下のことを行います:

  1. /etc/rc.confDAEMONS 行をパースし、ブート時にデーモンを起動します
  2. ブート中に /etc/rc.local を実行します
  3. シャットダウン中に /etc/rc.local.shutdown を実行します

Initscripts のエミュレーションはユーザーが systemd に移行するのを手助けする単純に過渡期の手段として存在しています、そして最終的には取り除かれます。ネイティブな systemd は設定の中心として rc.conf を使いません、/etc/rc.conf が使えなく成る前にネイティブの systemd 設定ファイルを使うことを推奨します。

Note: /etc/rc.local を置換するには、起動時に実行したいもののカスタムサービスファイルを書くことを推奨します。このセクションに方法を記述しています。
Note: Template:Keypress で再起動しないように /etc/inittab で設定していた場合、root で systemctl mask ctrl-alt-del.target を実行して systemd でも再設定する必要があります。

DAEMONS 行からの移行

純粋な systemd セットアップのためには、完全に /etc/rc.conf ファイルを削除して systemctl だけを使ってサービスを有効にしなくてはなりません。/etc/rc.confDAEMONS 行のそれぞれの <service_name> に対して次を実行します:

# systemctl enable <service_name>
Tip: 一般的に使われるデーモンの initscripts と systemd の比較表がここにあります。

<service_name>.service が存在しない場合:

  • ほとんど場合、systemd が違う名前を使っています。例えば、crond init デーモンは cronie.service に、alsa init デーモンは alsa-store.servicealsa-restore.service になっています。他にも network デーモンは、他のサービスファイルに置き換わっています (詳しくは Configuring Network を見て下さい)。
  • サービスファイルが systemd にない場合。その場合、起動中にサービスを作動させるのに rc.conf を使いつづける必要があります。
Tip: パッケージの中身を見て、どのサービス名でデーモン起動スクリプトが含まれているのか見ることができます。例:
$ pacman -Ql cronie
[...]
cronie /etc/rc.d/crond                            #DAEMONS 行で使われるデーモン initscript ("純粋な" systemd では使われません)
[...]
cronie /usr/lib/systemd/system/cronie.service     #対応する systemd のデーモンサービス
[...]
  • 最後に、サービスによっては、ユーザーの操作で有効にする必要がないものがあります。例えば、dbus.servicedbus-core がインストールされると自動で有効にされます。alsa-store.servicealsa-restore.service も systemd によって自動で有効にされます。利用できるサービスと状態をチェックするには systemctl コマンドを使います: systemctl status <service_name>

systemctl の基本的な使い方

systemd を管理したり内部情報を見るために使うメインのコマンドが systemctl です。システムの状態を確かめたりシステムやサービスを管理するために使うのは使い方の一部です。詳しくは man 1 systemctl を見て下さい。

Tip: systemctl コマンドに -H <user>@<host> を渡すと、リモートの systemd と対話できます。SSH を利用してリモートの systemd インスタンスに繋ぐのに使われます。
Note: systemadmsystemctl の公式グラフィカルフロントエンドです。systemd-ui-gitAUR パッケージが AUR から入手可能です。

システムの状態を分析する

実行中のユニットを一覧する:

$ systemctl

または:

$ systemctl list-units

失敗したユニットを一覧する:

$ systemctl --failed

実行可能なユニットファイルは /usr/lib/systemd/system//etc/systemd/system/ にあります(後者が優先的に使われます)。インストールされたユニットを一覧するには:

$ systemctl list-unit-files

ユニットを使う

ユニットには、例えば、サービス (.service) やマウントポイント (.mount)、デバイス (.device)、ソケット (.socket) などがあります。

systemctl を使うとき、一般的には拡張子 (suffix) を含むユニットファイルの完全な名前を指定する必要があります。例えば、sshd.socket のように。しかし、以下のような場合には省略形が存在します:

  • 拡張子が指定されない場合、systemctlは .service とみなします。例えば netcfgnetcfg.service は同じように扱われます。
  • マウントポイントは自動的に対応する .mount ユニットとして扱われます。例えば、/home を指定することは home.mount の指定と同じです。
  • マウントポイントと同じく、デバイスも自動的に対応する .device ユニットとして扱われます。従って、/dev/sda2 の指定は dev-sda2.device と同じです。

詳細は man systemd.unit を見てください。

いますぐユニットを実行:

# systemctl start <unit>

いますぐユニットを停止:

# systemctl stop <unit>

ユニットを再始動:

# systemctl restart <unit>

ユニットに設定を再読み込みするように通知:

# systemctl reload <unit>

ユニットの状態を表示(動いているかどうかなど):

$ systemctl status <unit>

有効化(起動時に自動で実行するよう設定)されているかどうか表示:

$ systemctl is-enabled <unit>

起動時に実行されるように有効化する:

# systemctl enable <unit>
Note: サービスに Install セクションがない場合、たいてい他のサービスから自動的に起動されます。手動でのインストールが必要な場合、以下のコマンドを使ってください (foo をサービスの名前に置換してください)。
# ln -s /usr/lib/systemd/system/foo.service /etc/systemd/system/graphical.target.wants/

システム起動時に実行されないように無効化する:

# systemctl disable <unit>

ユニットに関連する(ユニットファイルによってサポートされている)マニュアルページを参照する:

$ systemctl help <unit>

systemd をリロードし、新しい、もしくは変化のあったユニットをスキャンする:

# systemctl daemon-reload

電源管理

ローカルの systemd-logind のユーザーセッション中で、他のセッションがアクティブでなければ、ルート権限なしで次のコマンドが使えます。そうでなければ(他のユーザが tty でログインしている場合など)、systemd は自動的に root のパスワードを要求するでしょう。

再起動:

$ systemctl reboot

シャットダウンしてパワーオフ:

$ systemctl poweroff

サスペンド(待機):

$ systemctl suspend

ハイバネート(休止):

$ systemctl hibernate

ハイブリッドスリープ (or suspend-to-both):

$ systemctl hybrid-sleep

systemd でデスクトップ環境を動かす

グラフィカルログインを有効にするには、お好きな ディスプレイマネージャ デーモンを使って下さい (例: KDM)。現在、GDM, KDM, SLiM, XDM, LXDM, LightDM に対応したサービスファイルが存在します。

# systemctl enable kdm

これだけで動くはずですが、動かない場合、手動で default.target を設定するか、前のインストールを使います:

# ls -l /etc/systemd/system/default.target
/etc/systemd/system/default.target -> /usr/lib/systemd/system/graphical.target

シンボリックリンクを削除すれば systemd は保存した default.target (つまり graphical.target) を使うようになります。

# rm /etc/systemd/system/default.target

systemd-logind を使う

Note: 2012-10-30 現在、ConsoleKitsystemd-logindによって置き換えられ DE にログインする機構は変わりました。

ユーザーセッションの状態を確認するには loginctl を使います。サスペンドや外部デバイスのマウントなどの全ての PolicyKit アクションはそのまま変更せずに動きます。

$ loginctl show-session $XDG_SESSION_ID

カスタム .service ファイルを書く

See: Systemd/Services

依存関係を解決する

systemd ではユニットファイルを適切に書くことで依存関係を解決します。一番典型的なケースは、ユニット A が走る前に、ユニット A がユニット B を必要としている場合です。この場合、A の [Unit] セクションに Requires=BAfter=B を加えます。依存が必然ではない場合、代わりに Wants=BAfter=B を加えます。Wants=Requires=After= を含まないことに注意してください、もし After= を明記しなかったときは、2つのユニットは並行して実行されます。

基本的に、依存関係はターゲットではなくサービスに配置します。例えば、network.target はネットワークインターフェースを設定する全てのサービスによって使われるので、network.target が起動し終わってからあなたのカスタムユニットを起動させる順番にします。

タイプ

There are several different start-up types to consider when writing a custom service file. This is set with the Type= parameter in the [Service] section. See man systemd.service for a more detailed explanation.

  • Type=simple: systemd considers the service to be started up immediately. The process must not fork. Do not use this type if other services need to be ordered on this service, unless it is socket activated.
  • Type=forking: systemd considers the service started up once the process forks and the parent has exited. For classic daemons use this type unless you know that it is not necessary. You should specify PIDFile= as well so systemd can keep track of the main process.
  • Type=oneshot: This is useful for scripts that do a single job and then exit. You may want to set RemainAfterExit=yes as well so that systemd still considers the service as active after the process has exited.
  • Type=notify: Identical to Type=simple, but with the stipulation that the daemon will send a signal to systemd when it is ready. The reference implementation for this notification is provided by libsystemd-daemon.so.
  • Type=dbus: The service is considered ready when the specified BusName appears on DBus's system bus.

ユニットファイルを取り替える

/etc/systemd/system/ にあるユニットファイルは /usr/lib/systemd/system/ にあるファイルよりも優先されます。 To make your own version of a unit (which will not be destroyed by an upgrade), copy the old unit file from /usr/lib/ to /etc/ and make your changes there. Alternatively you can use .include to parse an existing service file and then override or add new options. For example, if you simply want to add an additional dependency to a service file, you may use:

/etc/systemd/system/<service-name>.service
.include /usr/lib/systemd/system/<service-name>.service

[Unit]
Requires=<new dependency>
After=<new dependency>

Then run the following for your changes to take effect:

# systemctl reenable <unit>
# systemctl restart <unit>
Tip: You can use systemd-delta to see which unit files have been overridden and what exactly has been changed.
As the provided unit files will be updated from time to time, use systemd-delta for system maintenance.

Vim でのユニットのシンタックスハイライト

公式リポジトリから vim-systemd をインストールすることで、Vim でのユニットファイルのシンタックスハイライトが可能です。

ターゲット

Systemd はランレベルと同じことをするためにターゲットを使いますが挙動には少し違いがあります。それぞれのターゲットはナンバリングの代わりに名前がつけられ、同時に複数のことが行えるようになっています。いくつかのターゲットには、他のターゲットのサービスを全て引継ぎ、サービスを追加する機能がつけられています。一般的な SystemVinit ランレベルに擬態する systemd ターゲットもあり、親しみのある telinit RUNLEVEL コマンドを使って使用するターゲットをスイッチすることが可能です。

現在のターゲットを獲得

systemd では runlevel の代わりに次を使います:

$ systemctl list-units --type=target

カスタムターゲットを作る

The runlevels that are assigned a specific purpose on vanilla Fedora installs; 0, 1, 3, 5, and 6; have a 1:1 mapping with a specific systemd target. Unfortunately, there is no good way to do the same for the user-defined runlevels like 2 and 4. If you make use of those it is suggested that you make a new named systemd target as /etc/systemd/system/<your target> that takes one of the existing runlevels as a base (you can look at /usr/lib/systemd/system/graphical.target as an example), make a directory /etc/systemd/system/<your target>.wants, and then symlink the additional services from /usr/lib/systemd/system/ that you wish to enable.

ターゲット表

SysV ランレベル systemd ターゲット Notes
0 runlevel0.target, poweroff.target Halt the system.
1, s, single runlevel1.target, rescue.target シングルユーザーモード。
2, 4 runlevel2.target, runlevel4.target, multi-user.target User-defined/Site-specific runlevels. By default, identical to 3.
3 runlevel3.target, multi-user.target Multi-user, non-graphical. Users can usually login via multiple consoles or via the network.
5 runlevel5.target, graphical.target マルチユーザー、グラフィカル。 Usually has all the services of runlevel 3 plus a graphical login.
6 runlevel6.target, reboot.target 再起動
emergency emergency.target 緊急シェル

現在のターゲットを変更する

systemd ではターゲットは"ターゲットユニット"として表現されます。ターゲットを変えるにはこのようにします:

# systemctl isolate graphical.target

これは現在のターゲットを変えるだけで、次の起動時には影響がありません。Sysvinit での、telinit 3telinit 5 のようなコマンドと同じです。

起動時のデフォルトターゲットを変更する

標準のターゲットは default.target で、デフォルトで graphical.target (おおよそランレベル 5 と同じ)にエイリアスされています。起動するデフォルトターゲットを変更するには、以下のカーネルパラメータのどれかをブートローダに加えてください:

Tip: .target 拡張子は省くことができます。
  • systemd.unit=multi-user.target (おおよそランレベル 3 と同じ),
  • systemd.unit=rescue.target (おおよそランレベル 1 と同じ).

もしくは、ブートローダではなく default.target を変えることもできます。systemctl を使います:

# systemctl enable multi-user.target

The effect of this command is outputted by systemctl; a symlink to the new default target is made at /etc/systemd/system/default.target. This works if, and only if:

[Install]
Alias=default.target

is in the target's configuration file. Currently, multi-user.target and graphical.target both have it.

Journal

systemd は、version 38 から自前のログシステムである journal を持っています。従って、syslog デーモンを起動する必要は既にありません。ログを読むには:

# journalctl

デフォルトで(/etc/systemd/journald.conf 内で Storage=auto に設定されている場合)、journal は /var/log/journal/ へ書き込みを行います。/var/log/journal/ ディレクトリが存在しない場合(例: あなたや何らかのプログラムがそれを削除した)、systemd は自動では作成しません、が代わりにログは /run/systemd/journal に書き込まれます。再起動時にこのログは消失してしまいます。

フィルタリング

journalctl を使って出力にフィルタをかけることができます。

例:

起動時からの全てのメッセージを表示:

# journalctl -b

However, often one is interested in messages not from the current, but from the previous boot (e.g. if an unrecoverable system crash happened). Currently, this feature is not implemented, though there was a diskussion at systemd-devel@lists.freedesktop.org (September/October 2012).

As a workaround you can use at the moment:

# journalctl --since=today | tac | sed -n '/-- Reboot --/{n;:r;/-- Reboot --/q;p;n;b r}' | tac

, provided, that the previous boot happened today. Be aware that, if there are many messages for the current day, the output of this command can be delayed for quite some time.

新しいメッセージを表示:

# journalctl -f

特定の実行ファイルによる全てのメッセージを表示:

# journalctl /usr/lib/systemd/systemd

特定のプロセスによる全てのメッセージを表示:

# journalctl _PID=1

特定のユニットによる全てのメッセージを表示:

# journalctl -u netcfg

詳しくは man journalctl, systemd.journal-fields や Lennert の blog post を見て下さい。

journal のサイズ制限

journal が永続的(不揮発性)の場合、デフォルトではファイルシステムの容量の 10% に制限されます。例えば、/var/log/journal が 50GiB の root パーティションにのっている場合、5GiB がログデータの上限になります。/etc/systemd/journald.confSystemMaxUse を変更すれば、最大サイズを変更できます。例えば制限を 50Mib にする場合、適切な行を次のようにアンコメント・編集します:

SystemMaxUse=50M

詳細は man journald.conf を参照してください。

journald と syslog の結合

古典的な syslog との互換性は、すべてのメッセージがソケット /run/systemd/journal/syslog に転送されることで実現されます。syslog を使うには、/dev/log/ の代わりにこのソケットを指定します(公式アナウンス)。syslog-ng は必要な設定ファイルを自動的に提供します。

# systemctl enable syslog-ng

最適化

Improve Boot Performance を見て下さい。

ブートプロセスを解析する

systemd-analyze を使う

Systemd provides a tool called systemd-analyze that allows you to analyze your boot process so you can see which unit files are causing your boot process to slow down. You can then optimize your system accordingly. You have to install python2-cairo and python2-gobject to use it.

To see how much time was spent in kernelspace and userspace on boot, simply use:

$ systemd-analyze
Tip: To see how much time was spent in the initramfs, append the timestamp hook to your HOOKS array in /etc/mkinitcpio.conf and as root, rebuild your initramfs with mkinitcpio -p linux

To list the started unit files, sorted by the time each of them took to start up:

$ systemd-analyze blame

You can also create a SVG file which describes your boot process graphically, similiar to Bootchart:

$ systemd-analyze plot > plot.svg

bootchart を使う

You could also use a version of bootchart to visualize the boot sequence. Since you are not able to put a second init into the kernel command line you won't be able to use any of the standard bootchart setups. However the bootchart2AUR package from AUR comes with an undocumented systemd service. After you've installed bootchart2 do:

# systemctl enable bootchart

Read the bootchart documentation for further details on using this version of bootchart.

Readahead

Systemd には readahead 機能があり、ほとんどの場合起動時間の短縮が望めます。しかし、どれくらい利益があるかは、あなたの使っているカーネルバージョンやハードドライブのタイプによって大きく変わります(遅くなることもあるかもしれません)。有効にするには次を実行してください:

# systemctl enable systemd-readahead-collect systemd-readahead-replay

readahed を機能させるには、何度か再起動させてやる必要があります。

トラブルシューティング

サービスを開始/再開するときに "Error: No space left on device"

Note: I don't know if this is a proper solution, but it seems to have worked for me (I didn't use the same value as they said to, however).

See this link: CrashPlan Support

Thanks to Fedora Forum for pointing me to this site.

シャットダウン/再起動にものすごく時間がかかる

シャットダウンに非常に長い時間がかかる(もしくはフリーズする)場合、サービスが存在していないことが問題かもしれません。Systemd はサービスを kill する前に終了するのを待ちます。なにが原因か知るにはこの記事を見て下さい。

短いプロセスがログを出力しない

systemctl -u foounit.service が短いプロセスについてなにも表示しない場合、かわりに PID を見て下さい。例えば、systemd-modules-load.service が落ちたとき、systemctl status systemd-modules-load によってそれが PID 123 として動いているとわかったら、その PID の journal の出力を見ることができます、journalctl -b _PID=123。 Metadata fields for the journal such as _SYSTEMD_UNIT and _COMM are collected asynchronously and rely on the /proc directory for the process existing. Fixing this requires fixing the kernel to provide this data via a socket connection, similar to SCM_CREDENTIALS.

See also