diff options
| -rw-r--r-- | Makefile-man.am | 2 | ||||
| -rw-r--r-- | man/systemctl.xml | 17 | ||||
| -rw-r--r-- | man/systemd.generator.xml | 346 |
3 files changed, 359 insertions, 6 deletions
diff --git a/Makefile-man.am b/Makefile-man.am index 7503abb8b6..d0fb9aa1ae 100644 --- a/Makefile-man.am +++ b/Makefile-man.am @@ -99,6 +99,7 @@ MANPAGES += \ man/systemd.automount.5 \ man/systemd.device.5 \ man/systemd.exec.5 \ + man/systemd.generator.7 \ man/systemd.journal-fields.7 \ man/systemd.kill.5 \ man/systemd.link.5 \ @@ -1791,6 +1792,7 @@ EXTRA_DIST += \ man/systemd.device.xml \ man/systemd.directives.xml \ man/systemd.exec.xml \ + man/systemd.generator.xml \ man/systemd.index.xml \ man/systemd.journal-fields.xml \ man/systemd.kill.xml \ diff --git a/man/systemctl.xml b/man/systemctl.xml index 1c738cede6..ee6127c0b5 100644 --- a/man/systemctl.xml +++ b/man/systemctl.xml @@ -1367,12 +1367,16 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service <term><command>daemon-reload</command></term> <listitem> - <para>Reload systemd manager configuration. This will reload - all unit files and recreate the entire dependency - tree. While the daemon is being reloaded, all sockets systemd - listens on behalf of user configuration will stay - accessible.</para> <para>This command should not be confused - with the <command>reload</command> command.</para> + <para>Reload systemd manager configuration. This will + rerun all generators (see + <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>), + reload all unit files, and recreate the entire dependency + tree. While the daemon is being reloaded, all sockets + systemd listens on behalf of user configuration will stay + accessible.</para> + + <para>This command should not be confused with the + <command>reload</command> command.</para> </listitem> </varlistentry> <varlistentry> @@ -1721,6 +1725,7 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>wall</refentrytitle><manvolnum>1</manvolnum></citerefentry>, <citerefentry><refentrytitle>systemd.preset</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>, <citerefentry><refentrytitle>glob</refentrytitle><manvolnum>7</manvolnum></citerefentry> </para> </refsect1> diff --git a/man/systemd.generator.xml b/man/systemd.generator.xml new file mode 100644 index 0000000000..519da15910 --- /dev/null +++ b/man/systemd.generator.xml @@ -0,0 +1,346 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [ +<!ENTITY % entities SYSTEM "custom-entities.ent" > +%entities; +]> + +<!-- + This file is part of systemd. + + Copyright 2015 Zbigniew Jędrzejewski-Szmek + + systemd is free software; you can redistribute it and/or modify it + under the terms of the GNU Lesser General Public License as published by + the Free Software Foundation; either version 2.1 of the License, or + (at your option) any later version. + + systemd is distributed in the hope that it will be useful, but + WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details. + + You should have received a copy of the GNU Lesser General Public License + along with systemd; If not, see <http://www.gnu.org/licenses/>. +--> + +<refentry id="systemd.generator"> + <refentryinfo> + <title>systemd.generator</title> + <productname>systemd</productname> + + <authorgroup> + <author> + <contrib>Developer</contrib> + <firstname>Lennart</firstname> + <surname>Poettering</surname> + <email>lennart@poettering.net</email> + </author> + </authorgroup> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd.generator</refentrytitle> + <manvolnum>7</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd.generator</refname> + <refpurpose>Systemd unit generators</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>/path/to/generator</command> + <arg choice="plain"><replaceable>normal-dir</replaceable></arg> + <arg choice="plain"><replaceable>early-dir</replaceable></arg> + <arg choice="plain"><replaceable>late-dir</replaceable></arg> + </cmdsynopsis> + + <para> + <literallayout><filename>/run/systemd/system-generators/*</filename> +<filename>/etc/systemd/system-generators/*</filename> +<filename>/usr/local/lib/systemd/system-generators/*</filename> +<filename>&systemgeneratordir;/*</filename></literallayout> + </para> + + <para> + <literallayout><filename>/run/systemd/user-generators/*</filename> +<filename>/etc/systemd/user-generators/*</filename> +<filename>/usr/local/lib/systemd/user-generators/*</filename> +<filename>&usergeneratordir;/*</filename></literallayout> + </para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + <para>Generators are small binaries that live in + <filename>&usergeneratordir;/</filename> and other directories + listed above. + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> + will execute those binaries very early at bootup and at + configuration reload time — before unit files are loaded. + Generators can dynamically generate unit files or create symbolic + links to unit files to add additional dependencies, thus extending + or overriding existing definitions. Their main purpose is to + convert configuration files that are not native unit files + dynamically into native unit files.</para> + + <para>Generators are loaded from a set of paths determined during + compilation, listed above. System and user generators are loaded + from directories with names ending in + <filename>system-generators/</filename> and + <filename>user-generators/</filename>, respectively. Generators + found in directories listed earlier override the ones with the + same name in directories lower in the list. A symlink to + <filename>/dev/null</filename> or an empty file can be used to + mask a generator, thereby preventing it from running. Please note + that the order of the two directories with the highest priority is + reversed with respect to the unit load path and generators in + <filename>/run</filename> overwrite those in + <filename>/etc</filename>.</para> + + <para>After installing new generators or updating the + configuration, <command>systemctl daemon-reloead</command> may be + executed. This will delete the previous configuration created by + generators, re-run all generators, and cause + <command>systemd</command> to reload units from disk. See + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + for more information. + </para> + </refsect1> + + <refsect1> + <title>Writing generators</title> + + <para>Generators are invoked with three arguments: paths to + runtime directories where generators can place their generated + unit files or symlinks.</para> + + <orderedlist> + <listitem> + <para><parameter>normal-dir</parameter></para> + <para>argv[1] may be used to override unit files in + <filename>/usr</filename>, but not those in + <filename>/etc</filename>. This means that unit files placed + in this directory take precedence over vendor unit + configuration but not over native user/administrator unit + configuration.</para> + </listitem> + + <listitem> + <para><parameter>early-dir</parameter></para> + <para>argv[2] may be used to override unit files in + <filename>/usr</filename> and in + <filename>/etc</filename>. This means that unit files placed + in this directory take precedence over all configuration, + both vendor and user/administrator.</para> + </listitem> + + <listitem> + <para><parameter>late-dir</parameter></para> + <para>argv[3] may be used to extend the unit file tree without + overridding any other unit files. Any native configuration + files supplied by the vendor or user/administrator take + precedence over the generated ones placed in this directory. + </para> + </listitem> + </orderedlist> + + <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>!). They + can however rely on the most basic kernel functionality to + be available, including mounted <filename>/sys</filename>, + <filename>/proc</filename>, <filename>/dev</filename>. + </para> + </listitem> + + <listitem> + <para> + Units written by generators are removed when 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, 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 + delay 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 user 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's often a better idea to just deprecate + old stuff instead of keeping it artificially alive. + </para> + </listitem> + </itemizedlist> + </refsect2> + </refsect1> + + <refsect1> + <title>Examples</title> + <example> + <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> + </example> + + <example> + <title>systemd-system-update-generator</title> + + <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 + <ulink url="http://www.freedesktop.org/wiki/Software/systemd/SystemUpdates">Implementing + Offline System Updates</ulink>.</para> + </example> + + <example> + <title>Debuging a generator</title> + + <programlisting>dir=$(mktemp -d) +SYSTEMD_LOG_LEVEL=debug &systemgeneratordir;/systemd-fstab-generator \ + "$dir" "$dir" "$dir" +find $dir</programlisting> + </example> + </refsect1> + + <refsect1> + <title>See also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-cryptsetup-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-debug-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-efi-boot-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-getty-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-hibernate-resume-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-system-update-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-sysv-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> +</refentry> |