man: make Notes section in systemd.geneator(5) toplevel
This is mostly a indentation change and rewrapping.
This commit is contained in:
Zbigniew Jędrzejewski-Szmek
parent
b82f27e7a3
commit
80efdacd08
|
|
@ -170,135 +170,112 @@
|
|||
the vendor or user/administrator take precedence.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</refsect1>
|
||||
|
||||
<refsect2>
|
||||
<title>Notes</title>
|
||||
<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>
|
||||
<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>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>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>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>Since
|
||||
<citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>
|
||||
|
||||
<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>
|
||||
is not available (see above), log messages have to be written to
|
||||
<filename>/dev/kmsg</filename> instead.</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>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>
|
||||
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>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>Regarding overriding semantics: there are two rules we
|
||||
try to follow when thinking about the overriding semantics:
|
||||
</para>
|
||||
<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>
|
||||
|
||||
<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>Regarding overriding semantics: there are two rules we try to follow
|
||||
when thinking about the overriding semantics:</para>
|
||||
|
||||
<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>
|
||||
<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>
|
||||
|
||||
<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>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>
|
||||
|
||||
<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>
|
||||
<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>
|
||||
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>
|
||||
<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>
|
||||
|
|
|
|||
Loading…
Reference in New Issue