diff options
| -rw-r--r-- | man/systemd.generator.xml | 267 |
1 files changed, 120 insertions, 147 deletions
diff --git a/man/systemd.generator.xml b/man/systemd.generator.xml index a41e43df0f..60ca0cecad 100644 --- a/man/systemd.generator.xml +++ b/man/systemd.generator.xml @@ -170,135 +170,112 @@ the vendor or user/administrator take precedence.</para> </listitem> </orderedlist> + </refsect1> + + <refsect1> + <title>Notes about writing generators</title> + + <itemizedlist> + <listitem> + <para>All generators are executed in parallel. That means all executables are + started at the very same time and need to be able to cope with this + parallelism. + </para> + </listitem> + + <listitem> + <para>Generators are run very early at boot and cannot rely on any external + services. They may not talk to any other process. That includes simple things + such as logging to + <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + or <command>systemd</command> itself (this means: no + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>)! + Non-essential file systems like <filename>/var</filename> and + <filename>/home</filename> are mounted after generators have run. Generators + can however rely on the most basic kernel functionality to be available, + including a mounted <filename>/sys</filename>, <filename>/proc</filename>, + <filename>/dev</filename>, <filename>/usr</filename>. + </para> + </listitem> + + <listitem> + <para>Units written by generators are removed when the configuration is + reloaded. That means the lifetime of the generated units is closely bound to + the reload cycles of <command>systemd</command> itself.</para> + </listitem> + + <listitem> + <para>Generators should only be used to generate unit files and symlinks to + them, not any other kind of configuration. Due to the lifecycle logic + mentioned above, generators are not a good fit to generate dynamic + configuration for other services. If you need to generate dynamic + configuration for other services, do so in normal services you order before + the service in question.</para> + </listitem> - <refsect2> - <title>Notes</title> - - <itemizedlist> - <listitem> - <para> - All generators are executed in parallel. That means all - executables are started at the very same time and need to - be able to cope with this parallelism. - </para> - </listitem> - - <listitem> - <para> - Generators are run very early at boot and cannot rely on - any external services. They may not talk to any other - process. That includes simple things such as logging to - <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>, - or <command>systemd</command> itself (this means: no - <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>)! - Non-essential file systems like - <filename>/var</filename> and <filename>/home</filename> - are mounted after generators have run. Generators - can however rely on the most basic kernel functionality to be - available, including a mounted <filename>/sys</filename>, - <filename>/proc</filename>, <filename>/dev</filename>, - <filename>/usr</filename>. - </para> - </listitem> - - <listitem> - <para> - Units written by generators are removed when the configuration - is reloaded. That means the lifetime of the generated - units is closely bound to the reload cycles of - <command>systemd</command> itself. - </para> - </listitem> - - <listitem> - <para> - Generators should only be used to generate unit files and symlinks to them, not any other kind of - configuration. Due to the lifecycle logic mentioned above, generators are not a good fit to generate - dynamic configuration for other services. If you need to generate dynamic configuration for other services, - do so in normal services you order before the service in question. - </para> - </listitem> - - <listitem> - <para> - Since - <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry> - is not available (see above), log messages have to be - written to <filename>/dev/kmsg</filename> instead. - </para> - </listitem> - - <listitem> - <para> - It is a good idea to use the - <varname>SourcePath=</varname> directive in generated unit - files to specify the source configuration file you are - generating the unit from. This makes things more easily - understood by the user and also has the benefit that - systemd can warn the user about configuration files that - changed on disk but have not been read yet by systemd. - </para> - </listitem> - - <listitem> - <para> - Generators may write out dynamic unit files or just hook - unit files into other units with the usual - <filename>.wants/</filename> or - <filename>.requires/</filename> symlinks. Often, it is - nicer to simply instantiate a template unit file from - <filename>/usr</filename> with a generator instead of - writing out entirely dynamic unit files. Of course, this - works only if a single parameter is to be used. - </para> - </listitem> - - <listitem> - <para> - If you are careful, you can implement generators in shell - scripts. We do recommend C code however, since generators - are executed synchronously and hence delay the - entire boot if they are slow. - </para> - </listitem> - - <listitem> - <para>Regarding overriding semantics: there are two rules we - try to follow when thinking about the overriding semantics: - </para> - - <orderedlist numeration="lowerroman"> - <listitem> - <para>User configuration should override vendor - configuration. This (mostly) means that stuff from - <filename>/etc</filename> should override stuff from - <filename>/usr</filename>.</para> - </listitem> - - <listitem> - <para>Native configuration should override non-native - configuration. This (mostly) means that stuff you - generate should never override native unit files for the - same purpose.</para> - </listitem> - </orderedlist> - - <para>Of these two rules the first rule is probably the more - important one and breaks the second one sometimes. Hence, - when deciding whether to use argv[1], argv[2], or argv[3], - your default choice should probably be argv[1].</para> - </listitem> - - <listitem> - <para> - Instead of heading off now and writing all kind of - generators for legacy configuration file formats, please - think twice! It is often a better idea to just deprecate - old stuff instead of keeping it artificially alive. - </para> - </listitem> - </itemizedlist> - </refsect2> + <listitem> + <para>Since + <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry> + + is not available (see above), log messages have to be written to + <filename>/dev/kmsg</filename> instead.</para> + </listitem> + + <listitem> + <para>It is a good idea to use the <varname>SourcePath=</varname> directive + in generated unit files to specify the source configuration file you are + generating the unit from. This makes things more easily understood by the + user and also has the benefit that systemd can warn the user about + configuration files that changed on disk but have not been read yet by + systemd.</para> + </listitem> + + <listitem> + <para>Generators may write out dynamic unit files or just hook unit files + into other units with the usual <filename>.wants/</filename> or + <filename>.requires/</filename> symlinks. Often, it is nicer to simply + instantiate a template unit file from <filename>/usr</filename> with a + generator instead of writing out entirely dynamic unit files. Of course, this + works only if a single parameter is to be used.</para> + </listitem> + + <listitem> + <para>If you are careful, you can implement generators in shell scripts. We + do recommend C code however, since generators are executed synchronously and + hence delay the entire boot if they are slow.</para> + </listitem> + + <listitem> + <para>Regarding overriding semantics: there are two rules we try to follow + when thinking about the overriding semantics:</para> + + <orderedlist numeration="lowerroman"> + <listitem> + <para>User configuration should override vendor configuration. This + (mostly) means that stuff from <filename>/etc</filename> should override + stuff from <filename>/usr</filename>.</para> + </listitem> + + <listitem> + <para>Native configuration should override non-native configuration. This + (mostly) means that stuff you generate should never override native unit + files for the same purpose.</para> + </listitem> + </orderedlist> + + <para>Of these two rules the first rule is probably the more important one + and breaks the second one sometimes. Hence, when deciding whether to use + argv[1], argv[2], or argv[3], your default choice should probably be + argv[1].</para> + </listitem> + + <listitem> + <para>Instead of heading off now and writing all kind of generators for + legacy configuration file formats, please think twice! It is often a better + idea to just deprecate old stuff instead of keeping it artificially alive. + </para> + </listitem> + </itemizedlist> </refsect1> <refsect1> @@ -307,22 +284,18 @@ <title>systemd-fstab-generator</title> <para><citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry> - converts <filename>/etc/fstab</filename> into native mount - units. It uses argv[1] as location to place the generated unit - files in order to allow the user to override - <filename>/etc/fstab</filename> with her own native unit files, - but also to ensure that <filename>/etc/fstab</filename> - overrides any vendor default from <filename>/usr</filename>. - </para> - - <para>After editing <filename>/etc/fstab</filename>, the user - should invoke <command>systemctl daemon-reload</command>. This - will re-run all generators and cause <command>systemd</command> - to reload units from disk. To actually mount new directories - added to <filename>fstab</filename>, <command>systemctl start - <replaceable>/path/to/mountpoint</replaceable></command> or - <command>systemctl start local-fs.target</command> may be used. - </para> + converts <filename>/etc/fstab</filename> into native mount units. It uses + argv[1] as location to place the generated unit files in order to allow the + user to override <filename>/etc/fstab</filename> with her own native unit + files, but also to ensure that <filename>/etc/fstab</filename> overrides any + vendor default from <filename>/usr</filename>.</para> + + <para>After editing <filename>/etc/fstab</filename>, the user should invoke + <command>systemctl daemon-reload</command>. This will re-run all generators and + cause <command>systemd</command> to reload units from disk. To actually mount + new directories added to <filename>fstab</filename>, <command>systemctl start + <replaceable>/path/to/mountpoint</replaceable></command> or <command>systemctl + start local-fs.target</command> may be used.</para> </example> <example> @@ -331,9 +304,9 @@ <para><citerefentry><refentrytitle>systemd-system-update-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry> temporarily redirects <filename>default.target</filename> to <filename>system-update.target</filename>, if a system update is - scheduled. Since this needs to override the default user - configuration for <filename>default.target</filename>, it uses - argv[2]. For details about this logic, see + scheduled. Since this needs to override the default user configuration for + <filename>default.target</filename>, it uses argv[2]. For details about this + logic, see <citerefentry><refentrytitle>systemd.offline-updates</refentrytitle><manvolnum>7</manvolnum></citerefentry>. </para> </example> |