「DeveloperWiki:Systemd」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
(前書きの訳出)
(→‎sysctl.d: 訳出)
 
(同じ利用者による、間の4版が非表示)
6行目: 6行目:
   
 
===ユニット===
  
===ユニット===
  +
* 存在するときはいつでもアップストリームのユニットファイルを使う
−
* Use the upstream unit files whenever they exist
  
  +
* Arch 固有のことをしないようにする。これは将来アップストリームがユニットファイルを提供するようになった後に、動作を変更しない可能性を最大化します。特に {{ic|EnvironmentFile=}} は、Arch 固有の {{ic|/etc/conf.d}} を指しているときは特に避けるようにしてください
−
* Try not to do anything Arch-specific. This will maximize chances of not having to change behavior in the future once the unit files are provided by upstream. In particular avoid {{ic|EnvironmentFile=}}, especially if it points to the Arch-specific {{ic|/etc/conf.d}}
  
−
* Always separate initialization behavior from the actual daemon behavior. If necessary, use a separate unit for the initialization, blocked on a ConditionFoo from {{ic|systemd.unit(5)}}. An example of this is {{ic|sshd.service}} and {{ic|sshdgenkeys.service}}.
 +
* 常に初期化の動作と実際のデーモンの動作を分ける。必要であれば、初期化のために別のユニットファイルを使って、{{ic|systemd.unit(5)}} の ConditionFoo によりブロックされるようにしてください。このような例は {{ic|sshd.service}} と {{ic|sshdgenkeys.service}} があります。
   
−
Not using an {{ic|EnvironmentFile=}} is OK if:
 +
以下の場合には {{ic|EnvironmentFile=}} を使わなくて構いません。
  +
* デーモンが、同じ設定を指定できる設定ファイルを持っている
−
* Either the daemon has its own configuration file where the same settings can be specified
  
  +
* デフォルトのサービスファイルがほとんどの一般的なケースで "そのまま動く" 場合。動作を変えたいユーザーはこの場合デフォルトのサービスファイルをオーバーライドする必要があります。適切なデフォルトサービスファイルを提供することが不可能な場合は、ケースバイケースの方針で議論する必要があります
−
* The default service file "just works" in the most common case. Users who want to change the behavior should then override the default service file. If it is not possible to provide a sane default service file, it should be discussed on a case-by-case basis
  
   
  +
以下はサービスファイルに関するいくつかのコメントで、現在の動作を大まかに維持して、変な動作を避けることが前提です。
−
A few comments about service files, assuming current behavior should be roughly preserved, and fancy behavior avoided:
  
−
* If your service requires the network to be configured before it starts, use {{ic|After=network.target}}. Do '''not''' use {{ic|Wants=network.target}} or {{ic|Requires=network.target}}
 +
* サービスの開始前にネットワークが設定されている必要があるときは、{{ic|After=network.target}} を使ってください。{{ic|Wants=network.target}} や {{ic|Requires=network.target}} は '''使わない''' でください
−
* Use {{ic|Type=forking}}, unless you know it's not necessary
 +
* 必要でないと分かっているとき以外は {{ic|Type=forking}} を使ってください
  +
** たくさんのデーモンが、始めのプロセスの終了を準備ができたことを知らせるために使います。問題を最小化するため、このモードを使うと一番安全です
−
** Many daemons use the exit of the first process to signal that they are ready, so to minimize problems, it is safest to use this mode
  
  +
** どのプロセスがメインのプロセスか systemd が確実に理解できるように、デーモンに pidfile を生成させて、systemd に {{ic|PIDFile=}} を使って pidfile を指し示してください
−
** To make sure that systemd is able to figure out which process is the main process, tell the daemon to write a pidfile and point systemd to it using {{ic|PIDFile=}}
  
  +
** そのデーモンが dbus により有効化される・socket により有効化される・明示的に {{ic|Type=notify}} をサポートしている、のいずれかの場合、話は変わってきますが、現在は少数のデーモンにのみ当てはまります
−
** If the daemon in question is dbus-activated, socket-activated, or specifically supports {{ic|Type=notify}}, that's a different matter, but currently only the case for a minority of daemons
  
  +
* Arch の rc スクリプトは依存関係をサポートしていませんが、systemd においては必要に応じて追加される必要があります
−
* Arch's rc scripts do not support dependencies, but with systemd they should be added add where necessary
  
−
** The most typical case is that {{ic|A}} requires the service {{ic|B}} to be running before {{ic|A}} is started. In that case add {{ic|Requires=B}} and {{ic|After=B}} to {{ic|A}}.
 +
** 一番一般的なケースは、 {{ic|A}} が開始する前にサービス {{ic|B}} が起動している必要がある、という場合です。このケースでは {{ic|A}} に {{ic|Requires=B}} と {{ic|After=B}} を追加してください。
−
** If the dependency is optional then add {{ic|Wants=B}} and {{ic|After=B}} instead
 +
** 依存が任意の場合、代わりに {{ic|Wants=B}} と {{ic|After=B}} を追加してください
  +
** 依存は通常サービスに置かれ、依存先には置かれません。違ったことをしたくなった場合、何をしようとしているか知っておく必要があります。
−
** Dependencies are typically placed on services and not on targets
  
−
If you want to get fancy, you should know what you are doing.
  
   
 
====単純な慣習の例====
  
====単純な慣習の例====
77行目: 76行目:
 
|}
  
|}
   
  +
{{Note|ExecStart や ExecStop などのキーの値はシェル内で実行されず、{{ic|execv}} に渡されるだけであることを覚えておいてください。}}
−
{{Note|Keep in mind that values to keys such as ExecStart and ExecStop are '''not''' run within a shell, but only passed to {{ic|execv}}}}
  
   
 
===tmpfiles.d===
  
===tmpfiles.d===
  +
* サービスが開始されたときに必要な実行時ディレクトリやファイルを (いくつかの rc スクリプトが行うように) 作成する代わりに、{{ic|tmpfiles.d(5)}} 設定ファイルを {{ic|/usr/lib/tmpfiles.d}} に含めるようにしてください。
−
* Instead of creating necessary runtime directories and files when a service is started (as some rc scripts do), ship a {{ic|tmpfiles.d(5)}} config file in {{ic|/usr/lib/tmpfiles.d}}.
  
  +
* systemd に含まれている pacman フックは {{ic|systemd-tmpfiles --create foo.conf}} をインストール時に実行して、必要な実行時ファイルが次の起動時ではなくすぐに確実に作成されるようにします。
−
* A pacman hook included in systemd will run {{ic|systemd-tmpfiles --create foo.conf}} upon install to ensure the necessary runtime files are created right away, not just on the next boot
  
  +
{{Tip|この機能はたくさんの他のことにも使うことができ、例えば必要なファイルの書き込みを、/sys にさえ行うことができます。}}
−
{{Tip|This feature can be used for a whole lot of other things, e.g. for writing to arbitrary files, even in /sys}}
  
   
 
===modules-load.d===
  
===modules-load.d===
−
* Instead of loading necessary modules when a service is started (as some rc scripts do), ship a {{ic|modules-load.d(5)}} config file in {{ic|/usr/lib/modules-load.d}}.
 +
* サービスが開始されたときに必要なモジュールを (いくつかの rc スクリプトが行うように) 読み込む代わりに、{{ic|modules-load.d(5)}} 設定ファイルを {{ic|/usr/lib/modules-load.d}} に含めるようにしてください。
−
* Add {{ic|modprobe}} lines to {{ic|post_install}} (and {{ic|post_upgrade}} if needed) to ensure the necessary modules are loaded on install, not just on the next boot
 +
* {{ic|modprobe}} 行を {{ic|post_install}} (と必要であれば {{ic|post_upgrade}}) に追加して、必要なモジュールが次の起動時ではなくインストール時に確実に読み込まれるようにします。
   
 
===sysctl.d===
  
===sysctl.d===
  +
* 意見(dreisner): これは一般的に避けられるべきです。低レベルのカーネルの動作をパッケージと結びつけることは悪だと考えられているためです。
−
* IMO(dreisner): This should generally be avoided, as tying low level kernel behavior to a package might be considered evil.
  

2020年5月21日 (木) 12:06時点における最新版

このページは計画のためのものです。

パッケージ化メモ

ユニット

  • 存在するときはいつでもアップストリームのユニットファイルを使う
  • Arch 固有のことをしないようにする。これは将来アップストリームがユニットファイルを提供するようになった後に、動作を変更しない可能性を最大化します。特に EnvironmentFile= は、Arch 固有の /etc/conf.d を指しているときは特に避けるようにしてください
  • 常に初期化の動作と実際のデーモンの動作を分ける。必要であれば、初期化のために別のユニットファイルを使って、systemd.unit(5) の ConditionFoo によりブロックされるようにしてください。このような例は sshd.service と sshdgenkeys.service があります。

以下の場合には EnvironmentFile= を使わなくて構いません。

  • デーモンが、同じ設定を指定できる設定ファイルを持っている
  • デフォルトのサービスファイルがほとんどの一般的なケースで "そのまま動く" 場合。動作を変えたいユーザーはこの場合デフォルトのサービスファイルをオーバーライドする必要があります。適切なデフォルトサービスファイルを提供することが不可能な場合は、ケースバイケースの方針で議論する必要があります

以下はサービスファイルに関するいくつかのコメントで、現在の動作を大まかに維持して、変な動作を避けることが前提です。

  • サービスの開始前にネットワークが設定されている必要があるときは、After=network.target を使ってください。Wants=network.target や Requires=network.target は 使わない でください
  • 必要でないと分かっているとき以外は Type=forking を使ってください
    • たくさんのデーモンが、始めのプロセスの終了を準備ができたことを知らせるために使います。問題を最小化するため、このモードを使うと一番安全です
    • どのプロセスがメインのプロセスか systemd が確実に理解できるように、デーモンに pidfile を生成させて、systemd に PIDFile= を使って pidfile を指し示してください
    • そのデーモンが dbus により有効化される・socket により有効化される・明示的に Type=notify をサポートしている、のいずれかの場合、話は変わってきますが、現在は少数のデーモンにのみ当てはまります
  • Arch の rc スクリプトは依存関係をサポートしていませんが、systemd においては必要に応じて追加される必要があります
    • 一番一般的なケースは、 A が開始する前にサービス B が起動している必要がある、という場合です。このケースでは A に Requires=B と After=B を追加してください。
    • 依存が任意の場合、代わりに Wants=B と After=B を追加してください
    • 依存は通常サービスに置かれ、依存先には置かれません。違ったことをしたくなった場合、何をしようとしているか知っておく必要があります。

単純な慣習の例

rc script
#!/bin/bash

. /etc/rc.conf
. /etc/rc.d/functions

case "$1" in
  start)
    stat_busy "Starting NIS Server"
    /usr/sbin/ypserv
    if [ $? -gt 0 ]; then
      stat_fail
    else
      add_daemon ypserv
      stat_done
    fi
    ;;
  stop)
    stat_busy "Stopping NIS Server"
    killall -q /usr/sbin/ypserv
    if [ $? -gt 0 ]; then
      stat_fail
    else
      rm_daemon ypserv
      stat_done
    fi
    ;;
  restart)
    $0 stop
    sleep 1
    $0 start
    ;;
  *)
    echo "usage: $0 {start
 
systemd service file
[Unit]
Description=NIS/YP (Network Information Service) Server
Requires=rpcbind.service
After=network.target rpcbind.service

[Service]
Type=forking
PIDFile=/run/ypserv.pid
ExecStart=/usr/sbin/ypserv

[Install]
WantedBy=multi-user.target
ノート: ExecStart や ExecStop などのキーの値はシェル内で実行されず、execv に渡されるだけであることを覚えておいてください。

tmpfiles.d

  • サービスが開始されたときに必要な実行時ディレクトリやファイルを (いくつかの rc スクリプトが行うように) 作成する代わりに、tmpfiles.d(5) 設定ファイルを /usr/lib/tmpfiles.d に含めるようにしてください。
  • systemd に含まれている pacman フックは systemd-tmpfiles --create foo.conf をインストール時に実行して、必要な実行時ファイルが次の起動時ではなくすぐに確実に作成されるようにします。
ヒント: この機能はたくさんの他のことにも使うことができ、例えば必要なファイルの書き込みを、/sys にさえ行うことができます。

modules-load.d

  • サービスが開始されたときに必要なモジュールを (いくつかの rc スクリプトが行うように) 読み込む代わりに、modules-load.d(5) 設定ファイルを /usr/lib/modules-load.d に含めるようにしてください。
  • modprobe 行を post_install (と必要であれば post_upgrade) に追加して、必要なモジュールが次の起動時ではなくインストール時に確実に読み込まれるようにします。

sysctl.d

  • 意見(dreisner): これは一般的に避けられるべきです。低レベルのカーネルの動作をパッケージと結びつけることは悪だと考えられているためです。
「https://wiki.archlinux.jp/index.php?title=DeveloperWiki:Systemd&oldid=16362」から取得