2010-07-02 00:38:30 +00:00
|
|
|
<?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>
|
|
|
|
|
2010-07-02 07:51:25 +00:00
|
|
|
<para>For each path file, a matching unit file must
|
2010-07-02 00:38:30 +00:00
|
|
|
exist, describing the unit to activate when the path
|
2010-07-02 07:51:25 +00:00
|
|
|
changes. By default, a service by the same name as the
|
2010-07-02 00:38:30 +00:00
|
|
|
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>
|
2010-07-02 07:51:25 +00:00
|
|
|
API to monitor file systems. Due to that, it suffers by the
|
2010-07-02 00:38:30 +00:00
|
|
|
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
|
2010-07-02 07:51:25 +00:00
|
|
|
point in the file system hierarchy, a dependency
|
2010-07-02 00:38:30 +00:00
|
|
|
between both units is created automatically.</para>
|
2010-07-03 17:54:00 +00:00
|
|
|
|
|
|
|
<para>Unless <varname>DefaultDependencies=</varname>
|
|
|
|
is set to <option>false</option>, path units will
|
|
|
|
implicitly have dependencies of type
|
|
|
|
<varname>Conflicts=</varname> and
|
|
|
|
<varname>Before=</varname> on
|
|
|
|
<filename>shutdown.target</filename>. These ensure
|
|
|
|
that path units are terminated cleanly prior to system
|
|
|
|
shutdown. Only path units involved with early boot or
|
|
|
|
late system shutdown should disable this
|
|
|
|
option.</para>
|
2010-07-02 00:38:30 +00:00
|
|
|
</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
|
2010-07-02 07:51:25 +00:00
|
|
|
used to watch the mere existence of a
|
2010-07-02 00:38:30 +00:00
|
|
|
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
|
2010-07-02 07:51:25 +00:00
|
|
|
activate the configured unit whenever
|
2010-07-02 00:38:30 +00:00
|
|
|
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>)
|
2010-07-02 07:51:25 +00:00
|
|
|
at the time the path unit is activated,
|
2010-07-02 00:38:30 +00:00
|
|
|
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
|
2010-07-02 07:51:25 +00:00
|
|
|
specified, this value defaults to a
|
2010-07-02 00:38:30 +00:00
|
|
|
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
|
2010-07-02 07:51:25 +00:00
|
|
|
unit name of the path unit are named
|
|
|
|
identical, except for the
|
2010-07-02 00:38:30 +00:00
|
|
|
suffix.</para></listitem>
|
|
|
|
</varlistentry>
|
|
|
|
</variablelist>
|
|
|
|
</refsect1>
|
|
|
|
|
|
|
|
<refsect1>
|
|
|
|
<title>See Also</title>
|
|
|
|
<para>
|
2010-07-06 23:38:56 +00:00
|
|
|
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
|
2010-07-02 00:38:30 +00:00
|
|
|
<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>
|