|
HTML rendering created 2025-02-02 by Michael Kerrisk, author of The Linux Programming Interface. For details of in-depth Linux/UNIX system programming training courses that I teach, look here. Hosting by jambit GmbH. |
|
|
NAME | SYNOPSIS | DESCRIPTION | AUTOMATIC DEPENDENCIES | OPTIONS | SEE ALSO | COLOPHON |
|
|
|
SYSTEMD.PATH(5) systemd.path SYSTEMD.PATH(5)
systemd.path - Path unit configuration
path.path
A unit configuration file whose name ends in ".path" encodes
information about a path monitored by systemd, for path-based
activation.
This man page lists the configuration options specific to this
unit type. See systemd.unit(5) 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.
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 foo.path activates a matching service
foo.service. The unit to activate may be controlled by Unit= (see
below).
Internally, path units use the inotify(7) 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.
When a service unit triggered by a path unit terminates
(regardless whether it exited successfully or failed), monitored
paths are checked immediately again, and the service accordingly
restarted instantly. As protection against busy looping in this
trigger/start cycle, a start rate limit is enforced on the service
unit, see StartLimitIntervalSec= and StartLimitBurst= in
systemd.unit(5). Unlike other service failures, the error
condition that the start rate limit is hit is propagated from the
service unit to the path unit and causes the path unit to fail as
well, thus ending the loop.
Implicit Dependencies
The following dependencies are implicitly added:
• If a path unit is beneath another mount unit in the file
system hierarchy, both a requirement and an ordering
dependency between both units are created automatically.
• An implicit Before= dependency is added between a path unit
and the unit it is supposed to activate.
Default Dependencies
The following dependencies are added unless DefaultDependencies=no
is set:
• Path units will automatically have dependencies of type
Before= on paths.target, dependencies of type After= and
Requires= on sysinit.target, and have dependencies of type
Conflicts= and Before= on shutdown.target. 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 DefaultDependencies= option.
Path unit files may include [Unit] and [Install] sections, which
are described in systemd.unit(5).
Path unit files must include a [Path] section, which carries
information about the path or paths it monitors. The options
specific to the [Path] section of path units are the following:
PathExists=, PathExistsGlob=, PathChanged=, PathModified=,
DirectoryNotEmpty=
Defines paths to monitor for certain changes: PathExists= may
be used to watch the mere existence of a file or directory. If
the file specified exists, the configured unit is activated.
PathExistsGlob= works similarly, but checks for the existence
of at least one file matching the globbing pattern specified.
PathChanged= may be used to watch a file or directory and
activate the configured unit whenever it changes. It is not
activated on every write to the watched file but it is
activated if the file which was open for writing gets closed.
PathModified= is similar, but additionally it is activated
also on simple writes to the watched file. DirectoryNotEmpty=
may be used to watch a directory and activate the configured
unit whenever it contains at least one file.
The arguments of these directives must be absolute file system
paths.
Multiple directives may be combined, of the same and of
different types, to watch multiple paths. If the empty string
is assigned to any of these options, the list of paths to
watch is reset, and any prior assignments of these options
will not have any effect.
If a path already exists (in case of PathExists= and
PathExistsGlob=) or a directory already is not empty (in case
of DirectoryNotEmpty=) at the time the path unit is activated,
then the configured unit is immediately activated as well.
Something similar does not apply to PathChanged= and
PathModified=.
If the path itself or any of the containing directories are
not accessible, systemd will watch for permission changes and
notice that conditions are satisfied when permissions allow
that.
Note that files whose name starts with a dot (i.e. hidden
files) are generally ignored when monitoring these paths.
Unit=
The unit to activate when any of the configured paths changes.
The argument is a unit name, whose suffix is not ".path". 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 are named identical, except
for the suffix.
MakeDirectory=
Takes a boolean argument. If true, the directories to watch
are created before watching. This option is ignored for
PathExists= settings. Defaults to false.
DirectoryMode=
If MakeDirectory= is enabled, use the mode specified here to
create the directories in question. Takes an access mode in
octal notation. Defaults to 0755.
TriggerLimitIntervalSec=, TriggerLimitBurst=
Configures a limit on how often this path unit may be
activated within a specific time interval. The
TriggerLimitIntervalSec= may be used to configure the length
of the time interval in the usual time units "us", "ms", "s",
"min", "h", ... and defaults to 2s. See systemd.time(7) for
details on the various time units understood. The
TriggerLimitBurst= setting takes a positive integer value and
specifies the number of permitted activations per time
interval, and defaults to 200. Set either to 0 to disable any
form of trigger rate limiting. If the limit is hit, the unit
is placed into a failure mode, and will not watch the paths
anymore until restarted. Note that this limit is enforced
before the service activation is enqueued.
Added in version 250.
Check systemd.unit(5), systemd.exec(5), and systemd.kill(5) for
more settings.
Environment variables with details on the trigger will be set for
triggered units. See the section "Environment Variables Set or
Propagated by the Service Manager" in systemd.exec(5) for more
details.
systemd(1), systemctl(1), systemd.unit(5), systemd.service(5),
inotify(7), systemd.directives(7)
This page is part of the systemd (systemd system and service
manager) project. Information about the project can be found at
⟨http://www.freedesktop.org/wiki/Software/systemd⟩. If you have a
bug report for this manual page, see
⟨http://www.freedesktop.org/wiki/Software/systemd/#bugreports⟩.
This page was obtained from the project's upstream Git repository
⟨https://github.com/systemd/systemd.git⟩ on 2025-02-02. (At that
time, the date of the most recent commit that was found in the
repository was 2025-02-02.) If you discover any rendering
problems in this HTML version of the page, or you believe there is
a better or more up-to-date source for the page, or you have
corrections or improvements to the information in this COLOPHON
(which is not part of the original manual page), send a mail to
man-pages@man7.org
systemd 258~devel SYSTEMD.PATH(5)
Pages that refer to this page: systemd(1), systemd.unit(5), daemon(7), systemd.directives(7), systemd.index(7), systemd.special(7), systemd.syntax(7)
|
HTML rendering created 2025-02-02 by Michael Kerrisk, author of The Linux Programming Interface. For details of in-depth Linux/UNIX system programming training courses that I teach, look here. Hosting by jambit GmbH. |
|