DeveloperWiki:Systemd - 版の履歴

Ny-a: /* sysctl.d */ 訳出

2020-05-21T03:06:25Z

sysctl.d: 訳出

← 古い版		2020年5月21日 (木) 12:06時点における版
88行目:		88行目:

	===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.

Ny-a: /* modules-load.d */ 訳出

2020-05-21T03:06:10Z

modules-load.d: 訳出

← 古い版		2020年5月21日 (木) 12:06時点における版
84行目:		84行目:

	===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===

Ny-a: /* tmpfiles.d */ 訳出

2020-05-21T03:05:46Z

tmpfiles.d: 訳出

← 古い版		2020年5月21日 (木) 12:05時点における版
79行目:		79行目:

	===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===

Ny-a: /* 単純な慣習の例 */ 訳出

2020-05-21T02:54:09Z

単純な慣習の例: 訳出

← 古い版		2020年5月21日 (木) 11:54時点における版
76行目:		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===

Ny-a: /* ユニット */ 訳出

2020-05-20T02:48:38Z

ユニット: 訳出

← 古い版		2020年5月20日 (水) 11:48時点における版
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.

	====単純な慣習の例====		====単純な慣習の例====

Ny-a: 前書きの訳出

2020-05-20T02:46:42Z

前書きの訳出

← 古い版		2020年5月20日 (水) 11:46時点における版
1行目:		1行目:
	[[カテゴリ:DeveloperWiki]]		[[カテゴリ:DeveloperWiki]]
	[[en:DeveloperWiki:Systemd]]		[[en:DeveloperWiki:Systemd]]
			このページは計画のためのものです。
	This page is for planning.

	==パッケージ化メモ==		==パッケージ化メモ==

Ny-a: セクション見出しの訳出

2020-05-20T02:46:19Z

セクション見出しの訳出

← 古い版		2020年5月20日 (水) 11:46時点における版
1行目:		1行目:
	[[~~Category~~:DeveloperWiki]]		[[カテゴリ:DeveloperWiki]]
			[[en:DeveloperWiki:Systemd]]
	This page is for planning.		This page is for planning.

			==パッケージ化メモ==
	==Packaging notes==

	===~~Units~~===		===ユニット===
	* Use the upstream unit files whenever they exist		* Use the upstream unit files whenever they exist
	* 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}}		* 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}}
25行目:		26行目:
	If you want to get fancy, you should know what you are doing.		If you want to get fancy, you should know what you are doing.

	====~~Example of a simple conversion~~====		====単純な慣習の例====
	{\|		{\|
	\|- valign="top"		\|- valign="top"

Ny-a: en:DeveloperWiki:Systemd の版 600523 に同期

2020-05-20T02:45:43Z

en:DeveloperWiki:Systemd の版 600523 に同期

新規ページ

[[Category:DeveloperWiki]]
This page is for planning.

==Packaging notes==

===Units===
* Use the upstream unit files whenever they exist
* 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}}.

Not using an {{ic|EnvironmentFile=}} is OK if:
* 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}}
* Use {{ic|Type=forking}}, unless you know it's not necessary
** 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
** 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=}}
** 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'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}}.
** If the dependency is optional then add {{ic|Wants=B}} and {{ic|After=B}} instead
** Dependencies are typically placed on services and not on targets
If you want to get fancy, you should know what you are doing.

====Example of a simple conversion====
{|
|- valign="top"
| {{hc|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|stop|restart}"
esac}}
| {{hc|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}}
|}

{{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===
* 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}}.
* 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|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 {{ic|modules-load.d(5)}} config file in {{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

===sysctl.d===
* IMO(dreisner): This should generally be avoided, as tying low level kernel behavior to a package might be considered evil.