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

From ArchWiki
Jump to: navigation, search
m (systemd でデスクトップ環境を動かす)
m (ACPI 電源管理)
Line 208: Line 208:
 
オプションが設定されていない時に、systemd が使うデフォルトは: {{ic|1=HandlePowerKey=poweroff}}, {{ic|1=HandleSuspendKey=suspend}}, {{ic|1=HandleHibernateKey=hibernate}}, {{ic|1=HandleLidSwitch=suspend}}。
 
オプションが設定されていない時に、systemd が使うデフォルトは: {{ic|1=HandlePowerKey=poweroff}}, {{ic|1=HandleSuspendKey=suspend}}, {{ic|1=HandleHibernateKey=hibernate}}, {{ic|1=HandleLidSwitch=suspend}}。
  
グラフィカルセットアップを走らせていなかったり [[i3]] や [[awesome]] などシンプルなウィンドウマネージャしか使っていないシステムでは、以前から ACPI イベントに反応するものとして使われていた [[acpid]] デーモンで置き換えることができるかもしれません。
+
グラフィカルセットアップを走らせていなかったり [[i3]] や [[awesome (日本語)]] などシンプルなウィンドウマネージャしか使っていないシステムでは、以前から ACPI イベントに反応するものとして使われていた [[acpid]] デーモンで置き換えることができるかもしれません。
  
 
{{Note|Systemd は AC やバッテリの ACPI イベントを取り扱うことはできません、[[Laptop Mode Tools]] などのツールを使うには、依然として [[acpid]] が必要になります。}}
 
{{Note|Systemd は AC やバッテリの ACPI イベントを取り扱うことはできません、[[Laptop Mode Tools]] などのツールを使うには、依然として [[acpid]] が必要になります。}}
Line 216: Line 216:
 
{{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 {{ic|Handle}} options to {{ic|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.}}
 
{{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 {{ic|Handle}} options to {{ic|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.}}
+
{{Note|デフォルトの''カーネル''バックエンドに加え、Systemd は他のサスペンドバックエンド ([[Uswsusp]] [[TuxOnIce]] など)を使ってコンピュータをスリープ・ハイバネート状態にすることができます。}}
  
 
==== Sleep フック ====
 
==== Sleep フック ====
Line 293: Line 293:
 
* Argument 2: {{ic|suspend}}, {{ic|hibernate}} or {{ic|hybrid-sleep}}, depending on which is being invoked
 
* Argument 2: {{ic|suspend}}, {{ic|hibernate}} or {{ic|hybrid-sleep}}, depending on which is being invoked
  
In contrast to [[pm-utils]], systemd will run these scripts concurrently and not one after another.
+
[[pm-utils]] とは対照的に、systemd はスクリプトを(一つずつではなく)同時に実行します。
  
 
The output of any custom script will be logged by {{ic|systemd-suspend.service}}, {{ic|systemd-hibernate.service}} or {{ic|systemd-hybrid-sleep.service}}. You can see its output in systemd's [[#Journal|journal]]:
 
The output of any custom script will be logged by {{ic|systemd-suspend.service}}, {{ic|systemd-hibernate.service}} or {{ic|systemd-hybrid-sleep.service}}. You can see its output in systemd's [[#Journal|journal]]:

Revision as of 07:20, 2 January 2013

概括 help replacing me
systemd をインストールし、設定する方法についての文書です。
関連項目
systemd/User
systemd/Services
systemd FAQ
init Rosetta
udev

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 を使ってリムーバルディスクのマウントなどの操作を行います。
  • 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

  • /home パーティションが大きい場合は、/home を fsck でチェックしている間に /home を使わないサービスを起動できるようにしたほうがいいかもしれません。これを行うには /etc/fstab/home パーティションのエントリに次のオプションを追加してください:
noauto,x-systemd.automount

/home にアクセスがあるとまず fsck とマウントを行い、準備が整うまで /home への全てのファイルアクセスをカーネルによって遮断します。

  • 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

initramfs でアクティベイトしていない LVM ボリュームがある場合、lvm2 パッケージで提供されている、lvm-monitoring サービスを有効にしてください:

# systemctl enable lvm-monitoring

同じように、暗号化されたデバイスで LVM をブートの後ろでマウントしている場合(例: /etc/crypttab からマウント)、lvm2 パッケージの、lvm-on-crypt サービスを有効化してください:

# systemctl enable lvm-on-crypt

ACPI 電源管理

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

  • HandlePowerKey: パワーキーが押された時に行う動作を定めます。
  • HandleSuspendKey: サスペンドキーが押された時に行う動作を定めます。
  • HandleHibernateKey: ハイバネートキーが押された時に行う動作を定めます。
  • HandleLidSwitch: フタが閉じられた時に行う動作を定めます。

定めることができる動作は ignore, poweroff, reboot, halt, suspend, hibernate, kexec のどれかです。

オプションが設定されていない時に、systemd が使うデフォルトは: HandlePowerKey=poweroff, HandleSuspendKey=suspend, HandleHibernateKey=hibernate, HandleLidSwitch=suspend

グラフィカルセットアップを走らせていなかったり i3awesome (日本語) などシンプルなウィンドウマネージャしか使っていないシステムでは、以前から ACPI イベントに反応するものとして使われていた acpid デーモンで置き換えることができるかもしれません。

Note: Systemd は AC やバッテリの ACPI イベントを取り扱うことはできません、Laptop Mode Tools などのツールを使うには、依然として acpid が必要になります。

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 は他のサスペンドバックエンド (UswsuspTuxOnIce など)を使ってコンピュータをスリープ・ハイバネート状態にすることができます。

Sleep フック

systemctl suspend, systemctl hibernate, systemctl hybrid-sleep が実行された時、Systemd はマシンをスリープ状態にするのに pm-utils を使いません; カスタムフックを含む、pm-utils フックは実行されません。ただし、こうしたイベントでカスタムスクリプトを動かすために systemd は2つの似た機構を提供しています。

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

サービスファイルを suspend.target, hibernate.target, sleep.target にフックすることでサスペンド・ハイバネート前後に行うアクションを設定できます。ユーザー・システムアクションを行うにはファイルを分割する必要があります。ユーザーサービスファイルを作動させるには、# systemctl enable suspend@<user> && systemctl enable resume@<user>。例:

/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

root アクションでは (# 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

サービスファイルについてのヒント(詳しくは 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

pm-utils とは対照的に、systemd はスクリプトを(一つずつではなく)同時に実行します。

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 が起動し終わってからあなたのカスタムユニットを起動させる順番にします。

タイプ

カスタムサービスファイルを書くときにどのスタートアップタイプを使うべきか考える必要があります。タイプは [Service] セクションの Type= パラメータで設定します。より詳しい説明は man systemd.service を見て下さい。

  • Type=simple: systemd はサービスをすぐに起動するべきだと考えます。プロセスをフォークすることはできません。ソケットが有効になる前に他のサービスが必要なサービスに、このタイプを使ってはいけません。
  • 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: Type=simple と同じですが、利用可能になったときにデーモンが systemd に信号を送るように条件がつけられます。この通知のリファレンス実装は libsystemd-daemon.so によって提供されています。
  • Type=dbus: 指定の BusName が DBus のシステムバスに乗ったときに使うことができるサービス。

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

/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 システムを停止。
1, s, single runlevel1.target, rescue.target シングルユーザーモード。
2, 4 runlevel2.target, runlevel4.target, multi-user.target ユーザー定義・サイト指定ランレベル。デフォルトでは、3 と同一。
3 runlevel3.target, multi-user.target マルチユーザー、非グラフィカル。一般的にマルチコンソールやネットワークを介してログインするのに使われます。
5 runlevel5.target, graphical.target マルチユーザー、グラフィカル。通常、ランレベル 3 の全てのサービスにグラフィカルログインを付加。
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 には systemd-analyze というツールがあり、どのプロセスが起動を遅くしているのか調べるためにブートプロセスを解析することができます。それに応じてシステムを最適化することも可能です。使用するには python2-cairopython2-gobject をインストールする必要があります。

起動時、カーネルスペースとユーザースペースでどれくらい時間がかかっているか見るためには、シンプルに次を実行:

$ systemd-analyze
Tip: initramfs でどれくらい時間がかかったか見るためには、/etc/mkinitcpio.confHOOKS 行に timestamp フックを加え、root 権限で initramfs を mkinitcpio -p linux で再生成してください。

ユニットファイルを起動するのにかかった時間で並べて一覧するには:

$ systemd-analyze blame

Bootchart のように、ブートプロセスを視覚的にするために SVG ファイルを生成することもできます:

$ systemd-analyze plot > plot.svg

bootchart を使う

bootchart を使うことでブートシークエンスを視覚化できます。セカンド init をカーネルコマンドラインに加えることができないので、標準の bootchart セットアップはできません。しかし、AURbootchart2AUR パッケージにはドキュメント化されてない systemd サービスが付いています。bootchart2 をインストールした後に次を実行してください:

# systemctl enable bootchart

bootchart の使い方についての詳しい説明は bootchart documentation を読んで下さい。

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