[thirdparty/systemd.git] / man / systemd.path.xml

<?xml version='1.0'?> <!--*-nxml-*-->
<?xml-stylesheet type="text/xsl" href="http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl"?>
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
        "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">

<!--
  This file is part of systemd.

  Copyright 2010 Lennart Poettering

  systemd is free software; you can redistribute it and/or modify it
  under the terms of the GNU General Public License as published by
  the Free Software Foundation; either version 2 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
  General Public License for more details.

  You should have received a copy of the GNU General Public License
  along with systemd; If not, see <http://www.gnu.org/licenses/>.
-->

<refentry id="systemd.path">
        <refentryinfo>
                <title>systemd.path</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.path</refentrytitle>
                <manvolnum>5</manvolnum>
        </refmeta>

        <refnamediv>
                <refname>systemd.path</refname>
                <refpurpose>systemd path configuration files</refpurpose>
        </refnamediv>

        <refsynopsisdiv>
                <para><filename>systemd.path</filename></para>
        </refsynopsisdiv>

        <refsect1>
                <title>Description</title>

                <para>A unit configuration file whose name ends in
                <filename>.path</filename> encodes information about
                a path monitored by systemd, for
                path-based activation.</para>

                <para>This man page lists the configuration options
                specific to this unit type. See
                <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
                for the common options of all unit configuration
                files. The common configuration items are configured
                in the generic [Unit] and [Install] sections. The
                path specific configuration options are configured in
                the [Path] section.</para>

                <para>For each path file a matching unit file must
                exist, describing the unit to activate when the path
                changes. By default a service by the same name as the
                path (except for the suffix) is activated. Example: a
                path file <filename>foo.path</filename> activates a
                matching service <filename>foo.service</filename>. The
                unit to activate may be controlled by
                <varname>Unit=</varname> (see below).</para>

                <para>Internally, path units use the
                <citerefentry><refentrytitle>inotify</refentrytitle><manvolnum>7</manvolnum></citerefentry>
                API to monitor file systems. Due to that it suffers by the
                same limitations as inotify, and for example cannot be
                used to monitor files or directories changed by other
                machines on remote NFS file systems.</para>

                <para>If an path unit is beneath another mount
                point in the file system hierarchy a dependency
                between both units is created automatically.</para>
        </refsect1>

        <refsect1>
                <title>Options</title>

                <para>Path files must include a [Path] section,
                which carries information about the path(s) it
                monitors. The options specific to the [Path] section
                of path units are the following:</para>

                <variablelist>
                        <varlistentry>
                                <term><varname>PathExists=</varname></term>
                                <term><varname>PathChanged=</varname></term>
                                <term><varname>DirectoryNotEmpty=</varname></term>

                                <listitem><para>Defines paths to
                                monitor for certain changes:
                                <varname>PathExists=</varname> may be
                                used to watch the mere existance of a
                                file or directory. If the file
                                specified exists the configured unit
                                is
                                activated. <varname>PathChanged=</varname>
                                may be used to watch a file or
                                directory and activate the configured
                                unit whenever it changes or is
                                modified. <varname>DirectoryNotEmpty=</varname>
                                may be used to watch a directory and
                                activate the configured unit whenver
                                it contains at least one file.</para>

                                <para>The arguments of these
                                directives must be absolute file
                                system paths.</para>

                                <para>Multiple directives may be
                                combined, of the same and of different
                                types, to watch multiple paths.</para>

                                <para>If a path is already existing
                                (in case of
                                <varname>PathExists=</varname>) or a
                                directory already is not empty (in
                                case of
                                <varname>DirectoryNotEmpty=</varname>)
                                at the time the path unit is activated
                                then the configured unit is
                                immediately activated as
                                well. Something similar does not apply
                                to <varname>PathChanged=</varname>.
                                </para></listitem>
                        </varlistentry>
                        <varlistentry>
                                <term><varname>Unit=</varname></term>

                                <listitem><para>The unit to activate
                                when any of the configured paths
                                changes. The argument is a unit name,
                                whose suffix is not
                                <filename>.path</filename>. If not
                                specified this value defaults to a
                                service that has the same name as the
                                path unit, except for the suffix. (See
                                above.) It is recommended that the
                                unit name that is activated and the
                                unit name of the path unit is chosen
                                identical except for the
                                suffix.</para></listitem>
                        </varlistentry>
                </variablelist>
        </refsect1>

        <refsect1>
                  <title>See Also</title>
                  <para>
                          <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
                          <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
                          <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
                          <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
                          <citerefentry><refentrytitle>inotify</refentrytitle><manvolnum>7</manvolnum></citerefentry>
                  </para>
        </refsect1>

</refentry>
Commit	Line	Data
b36b082c LP	1	<?xml version='1.0'?> <!---nxml--->
	2	<?xml-stylesheet type="text/xsl" href="http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl"?>
	3	<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
	4	"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
	5
	6	<!--
	7	This file is part of systemd.
	8
	9	Copyright 2010 Lennart Poettering
	10
	11	systemd is free software; you can redistribute it and/or modify it
	12	under the terms of the GNU General Public License as published by
	13	the Free Software Foundation; either version 2 of the License, or
	14	(at your option) any later version.
	15
	16	systemd is distributed in the hope that it will be useful, but
	17	WITHOUT ANY WARRANTY; without even the implied warranty of
	18	MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
	19	General Public License for more details.
	20
	21	You should have received a copy of the GNU General Public License
	22	along with systemd; If not, see <http://www.gnu.org/licenses/>.
	23	-->
	24
	25	<refentry id="systemd.path">
	26	<refentryinfo>
	27	<title>systemd.path</title>
	28	<productname>systemd</productname>
	29
	30	<authorgroup>
	31	<author>
	32	<contrib>Developer</contrib>
	33	<firstname>Lennart</firstname>
	34	<surname>Poettering</surname>
	35	<email>lennart@poettering.net</email>
	36	</author>
	37	</authorgroup>
	38	</refentryinfo>
	39
	40	<refmeta>
	41	<refentrytitle>systemd.path</refentrytitle>
	42	<manvolnum>5</manvolnum>
	43	</refmeta>
	44
	45	<refnamediv>
	46	<refname>systemd.path</refname>
	47	<refpurpose>systemd path configuration files</refpurpose>
	48	</refnamediv>
	49
	50	<refsynopsisdiv>
	51	<para><filename>systemd.path</filename></para>
	52	</refsynopsisdiv>
	53
	54	<refsect1>
	55	<title>Description</title>
	56
	57	<para>A unit configuration file whose name ends in
	58	<filename>.path</filename> encodes information about
	59	a path monitored by systemd, for
	60	path-based activation.</para>
	61
	62	<para>This man page lists the configuration options
	63	specific to this unit type. See
	64	<citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
65	for the common options of all unit configuration
66	files. The common configuration items are configured
67	in the generic [Unit] and [Install] sections. The
68	path specific configuration options are configured in
69	the [Path] section.</para>
70
71	<para>For each path file a matching unit file must
72	exist, describing the unit to activate when the path
73	changes. By default a service by the same name as the
74	path (except for the suffix) is activated. Example: a
75	path file <filename>foo.path</filename> activates a
76	matching service <filename>foo.service</filename>. The
77	unit to activate may be controlled by
78	<varname>Unit=</varname> (see below).</para>
79
80	<para>Internally, path units use the
81	<citerefentry><refentrytitle>inotify</refentrytitle><manvolnum>7</manvolnum></citerefentry>
82	API to monitor file systems. Due to that it suffers by the
83	same limitations as inotify, and for example cannot be
84	used to monitor files or directories changed by other
85	machines on remote NFS file systems.</para>
86
87	<para>If an path unit is beneath another mount
88	point in the file system hierarchy a dependency
89	between both units is created automatically.</para>
90	</refsect1>
91
92	<refsect1>
93	<title>Options</title>
94
95	<para>Path files must include a [Path] section,
96	which carries information about the path(s) it
97	monitors. The options specific to the [Path] section
98	of path units are the following:</para>
99
100	<variablelist>
101	<varlistentry>
102	<term><varname>PathExists=</varname></term>
103	<term><varname>PathChanged=</varname></term>
104	<term><varname>DirectoryNotEmpty=</varname></term>
105
106	<listitem><para>Defines paths to
107	monitor for certain changes:
108	<varname>PathExists=</varname> may be
109	used to watch the mere existance of a
110	file or directory. If the file
111	specified exists the configured unit
112	is
113	activated. <varname>PathChanged=</varname>
114	may be used to watch a file or
115	directory and activate the configured
116	unit whenever it changes or is
117	modified. <varname>DirectoryNotEmpty=</varname>
118	may be used to watch a directory and
119	activate the configured unit whenver
120	it contains at least one file.</para>
121
122	<para>The arguments of these
123	directives must be absolute file
124	system paths.</para>
125
126	<para>Multiple directives may be
127	combined, of the same and of different
128	types, to watch multiple paths.</para>
129
130	<para>If a path is already existing
131	(in case of
132	<varname>PathExists=</varname>) or a
133	directory already is not empty (in
134	case of
135	<varname>DirectoryNotEmpty=</varname>)
136	at the time the path unit is activated
137	then the configured unit is
138	immediately activated as
139	well. Something similar does not apply
140	to <varname>PathChanged=</varname>.
141	</para></listitem>
142	</varlistentry>
143	<varlistentry>
144	<term><varname>Unit=</varname></term>
145
146	<listitem><para>The unit to activate
147	when any of the configured paths
148	changes. The argument is a unit name,
149	whose suffix is not
150	<filename>.path</filename>. If not
151	specified this value defaults to a
152	service that has the same name as the
153	path unit, except for the suffix. (See
154	above.) It is recommended that the
155	unit name that is activated and the
156	unit name of the path unit is chosen
157	identical except for the
158	suffix.</para></listitem>
159	</varlistentry>
160	</variablelist>
161	</refsect1>
162
163	<refsect1>
164	<title>See Also</title>
165	<para>
166	<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
167	<citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
168	<citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
169	<citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
170	<citerefentry><refentrytitle>inotify</refentrytitle><manvolnum>7</manvolnum></citerefentry>
171	</para>
172	</refsect1>
173
174	</refentry>