「DeveloperWiki:Systemd」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
(前書きの訳出)
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.
  
   
 
====単純な慣習の例====
  
====単純な慣習の例====

2020年5月20日 (水) 11:48時点における版

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

パッケージ化メモ

ユニット

  • 存在するときはいつでもアップストリームのユニットファイルを使う
  • 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
ノート: Keep in mind that values to keys such as ExecStart and ExecStop are not run within a shell, but only passed to execv

tmpfiles.d

  • Instead of creating necessary runtime directories and files when a service is started (as some rc scripts do), ship a tmpfiles.d(5) config file in /usr/lib/tmpfiles.d.
  • A pacman hook included in systemd will run systemd-tmpfiles --create foo.conf upon install to ensure the necessary runtime files are created right away, not just on the next boot
ヒント: 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

  • Instead of loading necessary modules when a service is started (as some rc scripts do), ship a modules-load.d(5) config file in /usr/lib/modules-load.d.
  • Add modprobe lines to post_install (and post_upgrade if needed) to ensure the necessary modules are loaded on install, not just on the next boot

sysctl.d

  • IMO(dreisner): This should generally be avoided, as tying low level kernel behavior to a package might be considered evil.
「https://wiki.archlinux.jp/index.php?title=DeveloperWiki:Systemd&oldid=16357」から取得