picnoir
/
Systemd
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

D-Bus docs: systemd1 fixes

This commit is contained in:
Daan De Meyer 2020-04-19 13:05:44 +02:00
parent 89fc6fd3ea
commit 2736c25ce2
1 changed files with 143 additions and 141 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

284
man/org.freedesktop.systemd1.xml
View File

@ -364,8 +364,8 @@ node /org/freedesktop/systemd1 {
invoked this method. <function>Unsubscribe()</function> reverts the signal subscription that
<function>Subscribe()</function> implements. It is not necessary to invoke
<function>Unsubscribe()</function> as clients are tracked. Signals are no longer sent out as soon as
all clients which previously asked for <function>Subscribe()</function> either closed the bus
connection or invoked <function>Unsubscribe()</function>.</para>
all clients which previously asked for <function>Subscribe()</function> either closed their connection
to the bus or invoked <function>Unsubscribe()</function>.</para>
<para><function>Reload()</function> may be invoked to reload all unit files.</para>
@ -376,57 +376,57 @@ node /org/freedesktop/systemd1 {
<para><function>Exit()</function> may be invoked to ask the manager to exit. This is not available for
the system manager and is useful only for user session managers.</para>
<para><function>Reboot()</function>, <function>PowerOff()</function>, <function>Halt()</function>,
<para><function>Reboot()</function>, <function>PowerOff()</function>, <function>Halt()</function>, or
<function>KExec()</function> may be used to ask for immediate reboot, powering down, halt or kexec
based reboot of the system. Note that this does not shut down any services and immediately transitions
into the reboot process. These functions are normally only called as last step of shutdown, and should
not be called directly. To shut down the machine it is a much better choice generally to invoke
<function>Reboot()</function> and <function>PoweOff()</function> on the
into the reboot process. These functions are normally only called as the last step of shutdown and should
not be called directly. To shut down the machine, it is generally a better idea to invoke
<function>Reboot()</function> or <function>PowerOff()</function> on the
<filename>systemd-logind</filename> manager object; see
<citerefentry><refentrytitle>org.freedesktop.login1</refentrytitle><manvolnum>5</manvolnum></citerefentry>
for more information.</para>
<para><function>SwitchRoot()</function> may be used to transition to a new root directory. This is
intended to be used by initial RAM disks. The call takes two arguments: the new root directory (which
needs to be specified), plus an init binary path (which may be left empty, in which case it is
intended to be used by initial RAM disks. The method takes two arguments: the new root directory (which
needs to be specified) and an init binary path (which may be left empty, in which case it is
automatically searched for). The state of the system manager will be serialized before the
transition. After the transition the manager binary on the main system is invoked and replaces the old
transition. After the transition, the manager binary on the main system is invoked and replaces the old
PID 1. All state will then be deserialized.</para>
<para><function>SetEnvironment()</function> may be used to alter the environment block that is passed
to all spawned processes. Takes a string array with environment variable assignments. Settings passed
will override previously set variables.</para>
to all spawned processes. It takes a string array of environment variable assignments. Any previously set
environment variables will be overridden.</para>
<para><function>UnsetEnvironment()</function> may be used to unset environment variables. Takes a
string array with environment variable names. All variables specified will be unset (if they have been
set previously) and no longer be passed to all spawned processes. This call has no effect for variables
<para><function>UnsetEnvironment()</function> may be used to unset environment variables. It takes a
string array of environment variable names. All variables specified will be unset (if they have been
set previously) and no longer be passed to all spawned processes. This method has no effect for variables
that were previously not set, but will not fail in that case.</para>
<para><function>UnsetAndSetEnvironment()</function> is a combination of
<function>UnsetEnvironment()</function> and <function>SetEnvironment()</function>. It takes two
lists. The first one is a list of variables to unset, the second one of assignments to set. If a
variable is listed in both, the variable is set after this call, i.e. the set list overrides the unset
list.</para>
lists. The first list contains variables to unset, the second one contains assignments to set. If a
variable is listed in both, the variable is set after this method returns, i.e. the set list overrides the
unset list.</para>
<para><function>ListUnitFiles()</function> returns an array of unit names plus their enablement
<para><function>ListUnitFiles()</function> returns an array of unit names and their enablement
status. Note that <function>ListUnit()</function> returns a list of units currently loaded into memory,
while <function>ListUnitFiles()</function> returns a list of unit <emphasis>files</emphasis> that could
be found on disk. Note that while most units are read directly from a unit file with the same name some
units are not backed by files, and some files (templates) cannot directly be loaded as units but need
to be instantiated.</para>
while <function>ListUnitFiles()</function> returns a list of unit <emphasis>files</emphasis> that were
found on disk. Note that while most units are read directly from a unit file with the same name, some
units are not backed by files and some files (templates) cannot directly be loaded as units but need
to be instantiated instead.</para>
<para><function>GetUnitFileState()</function> returns the current enablement status of specific unit
<para><function>GetUnitFileState()</function> returns the current enablement status of a specific unit
file.</para>
<para><function>EnableUnitFiles()</function> may be used to enable one or more units in the system (by
creating symlinks to them in <filename>/etc</filename> or <filename>/run</filename>). It takes a list
of unit files to enable (either just file names or full absolute paths if the unit files are residing
outside the usual unit search paths), and two booleans: the first controls whether the unit shall be
outside the usual unit search paths) and two booleans: the first controls whether the unit shall be
enabled for runtime only (true, <filename>/run</filename>), or persistently (false,
<filename>/etc</filename>). The second one controls whether symlinks pointing to other units shall be
replaced if necessary. This call returns one boolean and an array with the changes made. The boolean
replaced if necessary. This method returns one boolean and an array of the changes made. The boolean
signals whether the unit files contained any enablement information (i.e. an [Install]) section. The
changes list consists of structures with three strings: the type of the change (one of
changes array consists of structures with three strings: the type of the change (one of
<literal>symlink</literal> or <literal>unlink</literal>), the file name of the symlink and the
destination of the symlink. Note that most of the following calls return a changes list in the same
format.</para>
@ -441,40 +441,40 @@ node /org/freedesktop/systemd1 {
<para>Similarly, <function>LinkUnitFiles()</function> links unit files (that are located outside of the
usual unit search paths) into the unit search path.</para>
<para>Similarly, <function>PresetUnitFiles()</function> enables/disables one or more units file
<para>Similarly, <function>PresetUnitFiles()</function> enables/disables one or more unit files
according to the preset policy. See
<citerefentry><refentrytitle>systemd.preset</refentrytitle><manvolnum>7</manvolnum></citerefentry> for more
information.</para>
<para>Similarly, <function>MaskUnitFiles()</function> masks unit files, and
<para>Similarly, <function>MaskUnitFiles()</function> masks unit files and
<function>UnmaskUnitFiles()</function> unmasks them again.</para>
<para><function>SetDefaultTarget()</function> changes the <filename>default.target</filename> link. See
<citerefentry><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry> for more
information</para>
information.</para>
<para><function>GetDefaultTarget()</function> retrieves the name of the unit to which
<filename>default.target</filename> is aliased</para>
<filename>default.target</filename> is aliased.</para>
<para><function>SetUnitProperties()</function> may be used to modify certain unit properties at
runtime. Not all properties may be changed at runtime, but many resource management settings (primarily
those listed in
<citerefentry><refentrytitle>systemd.cgroup</refentrytitle><manvolnum>5</manvolnum></citerefentry>)
may. The changes are applied instantly, and stored on disk for future boots, unless
may. The changes are applied instantly and stored on disk for future boots, unless
<varname>runtime</varname> is true, in which case the settings only apply until the next
reboot. <varname>name</varname> is the name of the unit to modify. <varname>properties</varname> are
the settings to set, encoded as an array of property name and value pairs. Note that this is not a
dictionary! Note that when setting array properties with this call this usually results in appending to
the pre-configured array. To reset the configured arrays set the property to an empty array first, then
append to it.</para>
dictionary! Also note that when setting array properties with this method usually results in appending to
the pre-configured array. To reset the configured arrays, set the property to an empty array first and
then append to it.</para>
<para><function>StartTransientUnit()</function> may be used to create and start a transient unit, which
<para><function>StartTransientUnit()</function> may be used to create and start a transient unit which
will be released as soon as it is not running or referenced anymore or the system is
rebooted. <varname>name</varname> is the unit name including suffix, and must be
rebooted. <varname>name</varname> is the unit name including its suffix and must be
unique. <varname>mode</varname> is the same as in <function>StartUnit()</function>,
<varname>properties</varname> contains properties of the unit, specified like in
<function>SetUnitProperties()</function>. <varname>aux</varname> is currently unused and should be
passed as empty array. See the <ulink
passed as an empty array. See the <ulink
url="http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/">New Control Group
Interface</ulink> for more information how to make use of this functionality for resource control
purposes.</para>
@ -484,7 +484,7 @@ node /org/freedesktop/systemd1 {
<title>Signals</title>
<para>Note that most signals are sent out only after <function>Subscribe()</function> has been invoked
by at least one client. Make sure to invoke this call when subscribing to these signals!</para>
by at least one client. Make sure to invoke this method when subscribing to these signals!</para>
<para><function>UnitNew()</function> and <function>UnitRemoved()</function> are sent out each time a
new unit is loaded or unloaded. Note that this has little to do with whether a unit is available on
@ -493,24 +493,24 @@ node /org/freedesktop/systemd1 {
<para><function>JobNew()</function> and <function>JobRemoved()</function> are sent out each time a new
job is queued or dequeued. Both signals take the numeric job ID, the bus path and the primary unit name
for this job as argument. <function>JobRemoved()</function> also includes a result string, being one of
<literal>done</literal>, <literal>canceled</literal>, <literal>timeout</literal>,
<literal>failed</literal>, <literal>dependency</literal>,
for this job as arguments. <function>JobRemoved()</function> also includes a result string which is one
of <literal>done</literal>, <literal>canceled</literal>, <literal>timeout</literal>,
<literal>failed</literal>, <literal>dependency</literal>, or
<literal>skipped</literal>. <literal>done</literal> indicates successful execution of a
job. <literal>canceled</literal> indicates that a job has been canceled (via
<function>CancelJob()</function> above) before it finished execution (this doesn't necessarily mean
though that the job operation is actually cancelled too, see above). <literal>timeout</literal>
indicates that the job timeout was reached. <literal>failed</literal> indicates that the job
failed. <literal>dependency</literal> indicates that a job this job has been depending on failed and
the job hence has been removed too. <literal>skipped</literal> indicates that a job was skipped because
it didn't apply to the units current state.</para>
failed. <literal>dependency</literal> indicates that a job this job depended on failed and the job hence
was removed as well. <literal>skipped</literal> indicates that a job was skipped because
it didn't apply to the unit's current state.</para>
<para><function>StartupFinished()</function> is sent out when startup finished. It carries six
microsecond timespan values each indicating how much boot time has been spent in the firmware (if
<para><function>StartupFinished()</function> is sent out when startup finishes. It carries six
microsecond timespan values, each indicating how much boot time has been spent in the firmware (if
known), in the boot loader (if known), in the kernel initialization phase, in the initrd (if known), in
userspace and in total. These values may also be calculated from the
<varname>FirmwareTimestampMonotonic</varname>, <varname>LoaderTimestampMonotonic</varname>,
<varname>InitRDTimestampMonotonic</varname>, <varname>UserspaceTimestampMonotonic</varname>,
<varname>InitRDTimestampMonotonic</varname>, <varname>UserspaceTimestampMonotonic</varname>, and
<varname>FinishTimestampMonotonic</varname> properties (see below).</para>
<para><function>UnitFilesChanged()</function> is sent out each time the list of enabled or masked unit
@ -518,7 +518,7 @@ node /org/freedesktop/systemd1 {
<para><function>Reloading()</function> is sent out immediately before a daemon reload is done (with the
boolean parameter set to True) and after a daemon reload is completed (with the boolean parameter set
to False). This may be used by UIs to optimize UI updates</para>
to False). This may be used by UIs to optimize UI updates.</para>
</refsect2>
<refsect2>
@ -530,15 +530,15 @@ node /org/freedesktop/systemd1 {
<para>The others:</para>
<para><varname>Version</varname> encodes the version string of the running systemd instance. Note that
the version string is purely informational, it should not be parsed, one may not assume the version to
the version string is purely informational. It should not be parsed and one may not assume the version to
be formatted in any particular way. We take the liberty to change the versioning scheme at any time and
it is not part of the API.</para>
it is not part of the public API.</para>
<para><varname>Features</varname> encodes the features that have been enabled and disabled for this
build. Enabled options are prefixed with +, disabled options with -.</para>
<para><varname>Tainted</varname> encodes a couple of taint flags, as a colon-separated list. When
systemd detects it is run on a system with certain problems it will set an appropriate taint
<para><varname>Tainted</varname> encodes a couple of taint flags as a colon-separated list. When
systemd detects it is running on a system with certain problems, it will set an appropriate taint
flag. Taints may be used to lower the chance of bogus bug reports. The following taints are currently
known: <literal>split-usr</literal>, <literal>mtab-not-symlink</literal>,
<literal>cgroups-missing</literal>, <literal>local-hwclock</literal>. <literal>split-usr</literal> is
@ -556,26 +556,27 @@ node /org/freedesktop/systemd1 {
<varname>KernelTimestamp</varname>, <varname>KernelTimestampMonotonic</varname>,
<varname>InitRDTimestamp</varname>, <varname>InitRDTimestampMonotonic</varname>,
<varname>UserspaceTimestamp</varname>, <varname>UserspaceTimestampMonotonic</varname>,
<varname>FinishTimestamp</varname>, <varname>FinishTimestampMonotonic</varname> encode
<varname>FinishTimestamp</varname>, and <varname>FinishTimestampMonotonic</varname> encode
<constant>CLOCK_REALTIME</constant> and <constant>CLOCK_MONOTONIC</constant> microsecond timestamps
taken when the firmware first began execution, when the boot loader first began execution, when the
kernel first began execution, when the initrd first began execution, when the main systemd instance
began execution and finally, when all queued startup jobs finished execution. These values are useful
for determining boot-time performance. Note that as monotonic time begins with the kernel startup the
KernelTimestampMonotonic timestamp will always be 0, and FirmwareTimestampMonotonic and
LoaderTimestampMonotonic are to be read as negative values. Also, not all fields are available,
depending on the used firmware, boot loader or initrd implementation. In these cases the respective
pairs of timestamps are both 0, indicating that no data is available.</para>
for determining boot-time performance. Note that as monotonic time begins with the kernel startup, the
<varname>KernelTimestampMonotonic</varname> timestamp will always be 0 and
<varname>FirmwareTimestampMonotonic</varname> and <varname>LoaderTimestampMonotonic</varname> are to
be read as negative values. Also, not all fields are always available, depending on the used firmware,
boot loader or initrd implementation. In these cases the respective pairs of timestamps are both 0,
indicating that no data is available.</para>
<para>Similarly, the <varname>SecurityStartTimestamp</varname>,
<varname>GeneratorsStartTimestamp</varname> and <varname>LoadUnitTimestamp</varname> (plus their
<varname>GeneratorsStartTimestamp</varname> and <varname>LoadUnitTimestamp</varname> (as well as their
monotonic and stop counterparts) expose performance data for uploading the security policies to the
kernel (such as the SELinux, IMA, or SMACK policies), for running the generator tools and for loading
the unit files</para>
the unit files.</para>
<para><varname>NNames</varname> encodes how many unit names are currently known. This only includes
names of units that are currently loaded and can be more than actually loaded units since units may
have more than one name.</para>
names of units that are currently loaded and can be more than the amount of actually loaded units since
units may have more than one name.</para>
<para><varname>NJobs</varname> encodes how many jobs are currently queued.</para>
@ -583,20 +584,21 @@ node /org/freedesktop/systemd1 {
<para><varname>NFailedJobs</varname> encodes how many jobs have ever failed in total.</para>
<para><varname>Progress</varname> encodes boot progress as floating point value between 0.0 and
<para><varname>Progress</varname> encodes boot progress as a floating point value between 0.0 and
1.0. This value begins at 0.0 at early-boot and ends at 1.0 when boot is finished and is based on the
number of executed and queued jobs. After startup this field is always 1.0 indicating a finished
number of executed and queued jobs. After startup, this field is always 1.0 indicating a finished
boot.</para>
<para><varname>Environment</varname> encodes the environment block passed to all executed services. It
may be altered with bus calls such as <function>SetEnvironment()</function> (see above).</para>
<para><varname>UnitPath</varname> encodes the currently active unit file search path. It is an array of
strings, each being one file system path</para>
file system paths encoded as strings.</para>
<para><varname>Virtualization</varname> contains a short ID string describing the virtualization
technology the system runs in. On bare-metal hardware this is the empty string, otherwise an identifier
such as <literal>kvm</literal>, <literal>vmware</literal> and so on. For a full list of IDs see
technology the system runs in. On bare-metal hardware this is the empty string. Otherwise, it contains
an identifier such as <literal>kvm</literal>, <literal>vmware</literal> and so on. For a full list of
IDs see
<citerefentry><refentrytitle>systemd-detect-virt</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
Note that only the "innermost" virtualization technology is exported here. This detects both
full-machine virtualizations (VMs) and shared-kernel virtualization (containers).</para>
@ -606,9 +608,9 @@ node /org/freedesktop/systemd1 {
<varname>ConditionArchitectures=</varname>.</para>
<para><varname>ControlGroup</varname> contains the root control group path of this system manager. Note
that the root path is encoded as empty string here (not as <literal>/</literal>!), so that it can be
that the root path is encoded as the empty string here (not as <literal>/</literal>!), so that it can be
appended to <filename>/sys/fs/cgroup/systemd</filename> easily. This value will be set to the empty
string for the host instance, and some other string for container instances</para>
string for the host instance and some other string for container instances.</para>
</refsect2>
<refsect2>
@ -623,9 +625,9 @@ node /org/freedesktop/systemd1 {
<function>ReenableUnitFiles()</function>, <function>LinkUnitFiles()</function>,
<function>PresetUnitFiles</function>, <function>MaskUnitFiles</function>, and similar) require
<interfacename>org.freedesktop.systemd1.manage-unit-files</interfacename>). Operations which modify the
exported environment ( <function>SetEnvironment()</function>, <function>UnsetEnvironment()</function>,
exported environment (<function>SetEnvironment()</function>, <function>UnsetEnvironment()</function>,
<function>UnsetAndSetEnvironment()</function>) require
<interfacename>org.freedesktop.systemd1.set-environment</interfacename>. <function>Reload()</function>
<interfacename>org.freedesktop.systemd1.set-environment</interfacename>. <function>Reload()</function>
and <function>Reexecute()</function> require
<interfacename>org.freedesktop.systemd1.reload-daemon</interfacename>.
</para>
@ -749,11 +751,12 @@ node /org/freedesktop/systemd1/unit/avahi_2ddaemon_2eservice {
<function>Restart()</function>, <function>TryRestart()</function>,
<function>ReloadOrRestart()</function>, <function>ReloadOrTryRestart()</function>,
<function>Kill()</function>, <function>ResetFailed()</function>, and
<function>SetProperties()</function> implement the same operation as the respective method calls on the
<interfacename>Manager</interfacename> object (see above), however operate on the unit object and hence
do not take a unit name parameter. Invoking the methods directly on the Manager object has the
advantage of not requiring a <function>GetUnit()</function> call to get the unit object for a specific
unit name. Calling the methods on the Manager object is hence a round trip optimization.</para>
<function>SetProperties()</function> implement the same operation as the respective methods on the
<interfacename>Manager</interfacename> object (see above). However, these methods operate on the unit
object and hence do not take a unit name parameter. Invoking the methods directly on the Manager
object has the advantage of not requiring a <function>GetUnit()</function> call to get the unit object
for a specific unit name. Calling the methods on the Manager object is hence a round trip
optimization.</para>
</refsect2>
<refsect2>
@ -774,9 +777,9 @@ node /org/freedesktop/systemd1/unit/avahi_2ddaemon_2eservice {
<varname>WantedBy</varname>, <varname>BoundBy</varname>, <varname>Conflicts</varname>,
<varname>ConflictedBy</varname>, <varname>Before</varname>, <varname>After</varname>,
<varname>OnFailure</varname>, <varname>Triggers</varname>, <varname>TriggeredBy</varname>,
<varname>PropagatesReloadTo</varname>, <varname>RequiresMountsFor</varname> contain arrays which encode
the dependencies and their inverse dependencies (where this applies), as configured in the unit file or
determined automatically. </para>
<varname>PropagatesReloadTo</varname>, and <varname>RequiresMountsFor</varname> contain arrays which encode
the dependencies and their inverse dependencies (where this applies) as configured in the unit file or
determined automatically.</para>
<para><varname>Description</varname> contains the human readable description string for the
unit.</para>
@ -784,16 +787,16 @@ node /org/freedesktop/systemd1/unit/avahi_2ddaemon_2eservice {
<para><varname>SourcePath</varname> contains the path to a configuration file this unit is
automatically generated from in case it is not a native unit (in which case it contains the empty
string). For example, all mount units generated from <filename>/etc/fstab</filename> have this field
set to this value.</para>
set to <filename>/etc/fstab</filename>.</para>
<para><varname>Documentation</varname> contains a string array with URLs of documentation for this
unit.</para>
<para><varname>LoadState</varname> contains a state value that reflects whether the configuration file
of this unit has been loaded. The following states are currently defined: <literal>loaded</literal>,
<literal>error</literal>, <literal>masked</literal>. <literal>loaded</literal> indicates that the
<literal>error</literal>, and <literal>masked</literal>. <literal>loaded</literal> indicates that the
configuration was successfully loaded. <literal>error</literal> indicates that the configuration failed
to load, the <varname>LoadError</varname> field (see below) contains information about the cause of
to load. The <varname>LoadError</varname> field (see below) contains information about the cause of
this failure. <literal>masked</literal> indicates that the unit is currently masked out (i.e. symlinked
to <filename>/dev/null</filename> or empty). Note that the <varname>LoadState</varname> is fully
orthogonal to the <varname>ActiveState</varname> (see below) as units without valid loaded
@ -803,7 +806,7 @@ node /org/freedesktop/systemd1/unit/avahi_2ddaemon_2eservice {
<para><varname>ActiveState</varname> contains a state value that reflects whether the unit is currently
active or not. The following states are currently defined: <literal>active</literal>,
<literal>reloading</literal>, <literal>inactive</literal>, <literal>failed</literal>,
<literal>activating</literal>, <literal>deactivating</literal>. <literal>active</literal> indicates
<literal>activating</literal>, and <literal>deactivating</literal>. <literal>active</literal> indicates
that unit is active (obviously...). <literal>reloading</literal> indicates that the unit is active and
currently reloading its configuration. <literal>inactive</literal> indicates that it is inactive and
the previous run was successful or no previous run has taken place yet. <literal>failed</literal>
@ -824,47 +827,46 @@ node /org/freedesktop/systemd1/unit/avahi_2ddaemon_2eservice {
later on than the common high-level states explained above.</para>
<para><varname>FragmentPath</varname> contains the unit file path this unit was read from, if there is
any (if not this contains the empty string).</para>
one (if not, it contains the empty string).</para>
<para><varname>UnitFileState</varname> encodes the install state of the unit file of
<varname>FragmentPath</varname>. It currently knows the following states: <literal>enabled</literal>,
<literal>enabled-runtime</literal>, <literal>linked</literal>, <literal>linked-runtime</literal>,
<literal>masked</literal>, <literal>masked-runtime</literal>, <literal>static</literal>,
<literal>disabled</literal>, <literal>invalid</literal>. <literal>enabled</literal> indicates that a
<literal>disabled</literal>, and <literal>invalid</literal>. <literal>enabled</literal> indicates that a
unit file is permanently enabled. <literal>enable-runtime</literal> indicates the unit file is only
temporarily enabled, and will no longer be enabled after a reboot (that means, it is enabled via
temporarily enabled and will no longer be enabled after a reboot (that means, it is enabled via
<filename>/run</filename> symlinks, rather than <filename>/etc</filename>). <literal>linked</literal>
indicates that a unit is linked into <filename>/etc</filename> permanently, <literal>linked</literal>
indicates that a unit is linked into <filename>/etc</filename> permanently. <literal>linked-runtime</literal>
indicates that a unit is linked into <filename>/run</filename> temporarily (until the next
reboot). <literal>masked</literal> indicates that the unit file is masked permanently,
<literal>masked-runtime</literal> indicates that it is only temporarily masked in
<filename>/run</filename>, until the next reboot. <literal>static</literal> indicates that the unit is
statically enabled, i.e. always enabled and doesn't need to be enabled
explicitly. <literal>invalid</literal> indicates that it could not be determined whether the unit file
is enabled.</para>
reboot). <literal>masked</literal> indicates that the unit file is masked permanently.
<literal>masked-runtime</literal> indicates that it is masked in <filename>/run</filename> temporarily
(until the next reboot). <literal>static</literal> indicates that the unit is statically enabled, i.e.
always enabled and doesn't need to be enabled explicitly. <literal>invalid</literal> indicates that it
could not be determined whether the unit file is enabled.</para>
<para><varname>InactiveExitTimestamp</varname>, <varname>InactiveExitTimestampMonotonic</varname>,
<varname>ActiveEnterTimestamp</varname>, <varname>ActiveEnterTimestampMonotonic</varname>,
<varname>ActiveExitTimestamp</varname>, <varname>ActiveExitTimestampMonotonic</varname>,
<varname>InactiveEnterTimestamp</varname>, <varname>InactiveEnterTimestampMonotonic</varname> contain
<constant>CLOCK_REALTIME</constant> and <constant>CLOCK_MONOTONIC</constant> 64-bit microsecond
<varname>InactiveEnterTimestamp</varname>, and <varname>InactiveEnterTimestampMonotonic</varname>
contain <constant>CLOCK_REALTIME</constant> and <constant>CLOCK_MONOTONIC</constant> 64-bit microsecond
timestamps of the last time a unit left the inactive state, entered the active state, exited the active
state, or entered an inactive state. These are the points in time where the unit transitioned
<literal>inactive</literal>/<literal>failed</literal> → <literal>activating</literal>,
<literal>activating</literal> → <literal>active</literal>, <literal>active</literal> →
<literal>deactivating</literal>, and finally <literal>deactivating</literal> →
<literal>inactive</literal>/<literal>failed</literal>. The fields are 0 in case such a transition has
not been recording on this boot yet.</para>
not yet been recorded on this boot.</para>
<para><varname>CanStart</varname>, <varname>CanStop</varname>, <varname>CanReload</varname> encodes as
booleans whether the unit supports the start, stop or reload operations. Even if a unit supports such
an operation the client might not necessary have the right privileges to execute them.</para>
<para><varname>CanStart</varname>, <varname>CanStop</varname>, and <varname>CanReload</varname> encode
as booleans whether the unit supports the start, stop or reload operations. Even if a unit supports
such an operation, the client might not necessary have the necessary privileges to execute them.</para>
<para><varname>CanIsolate</varname> encodes as boolean whether the unit may be started in isolation
<para><varname>CanIsolate</varname> encodes as a boolean whether the unit may be started in isolation
mode.</para>
<para><varname>Job</varname> encodes the job ID and job object path of the job currently scheduled or
executed for this unit, if there is any. If no job is scheduled or executed the job id field will be
executed for this unit, if there is any. If no job is scheduled or executed, the job id field will be
0.</para>
<para><varname>StopWhenUnneeded</varname>, <varname>RefuseManualStart</varname>,
@ -887,28 +889,28 @@ node /org/freedesktop/systemd1/unit/avahi_2ddaemon_2eservice {
<para><varname>ConditionTimestamp</varname> and <varname>ConditionTimestampMonotonic</varname> contain
the <constant>CLOCK_REALTIME</constant>/<constant>CLOCK_MONOTONIC</constant> microsecond timestamps of
the last time the configured conditions of the unit have been checked, or 0 if they have never been
the last time the configured conditions of the unit have been checked or 0 if they have never been
checked. Conditions are checked when a unit is requested to start.</para>
<para><varname>ConditionResult</varname> contains the condition result of the last time the configured
conditions of this unit were checked. </para>
<para><varname>Conditions</varname> contains all configured conditions of the unit. For each condition
<para><varname>Conditions</varname> contains all configured conditions of the unit. For each condition,
five fields are given: condition type (e.g. <varname>ConditionPathExists</varname>), whether the
condition is a trigger condition, whether the condition is reversed, the right hand side of the
condition (e.g. the path in case of <varname>ConditionPathExists</varname>), and the status. The status
can be 0, in which case the condition hasn't been checked yet, a positive value, in which case the
condition passed, or a negative value, in which case the condition failed. Currently only 0, +1, and -1
are used, but additional values may be used in the future, retaining the meaning of
zero/positive/negative values</para>
zero/positive/negative values.</para>
<para><varname>LoadError</varname> contains a pair of strings. If the unit failed to load (as encoded
in <varname>LoadState</varname>, see above), then this will include a D-Bus error pair consisting of
the error ID and an explanatory human readable string of what happened. If it succeeded to load this
the error ID and an explanatory human readable string of what happened. If it loaded successfully, this
will be a pair of empty strings.</para>
<para><varname>Transient</varname> contains a boolean that indicates whether the unit was created as
transient unit (i.e. via <function>CreateTransientUnit()</function> on the manager object)</para>
<para><varname>Transient</varname> contains a boolean that indicates whether the unit was created as a
transient unit (i.e. via <function>CreateTransientUnit()</function> on the manager object).</para>
</refsect2>
<refsect2>
@ -1073,10 +1075,10 @@ $ gdbus introspect --system --dest org.freedesktop.systemd1 \
last watchdog ping received from the service, or 0 if none was ever received.</para>
<para><varname>ExecStartPre</varname>, <varname>ExecStart</varname>, <varname>ExecStartPost</varname>,
<varname>ExecReload</varname>, <varname>ExecStop</varname>, <varname>ExecStop</varname> each are arrays
of structures each containing: the binary path to execute; an array with all arguments to pass to the
executed command, starting with argument 0; a boolean whether it should be considered a failure if the
process exits uncleanly; two pairs of
<varname>ExecReload</varname>, <varname>ExecStop</varname>, and <varname>ExecStop</varname> are arrays
of structures where each struct contains: the binary path to execute; an array with all arguments to
pass to the executed command, starting with argument 0; a boolean whether it should be considered a
failure if the process exits uncleanly; two pairs of
<constant>CLOCK_REALTIME</constant>/<constant>CLOCK_MONOTONIC</constant> microsecond timestamps when
the process began and finished running the last time, or 0 if it never ran or never finished running;
the PID of the process, or 0 if it has not run yet; the exit code and status of the last run. This
@ -1084,16 +1086,17 @@ $ gdbus introspect --system --dest org.freedesktop.systemd1 \
with runtime data.</para>
<para><varname>LimitCPU</varname> (and related properties) map more or less directly to the
corresponding settings in the service unit files, however are set to 18446744073709551615 (i.e. -1) if
they aren't set.</para>
corresponding settings in the service unit files except that if they aren't set, their value is
18446744073709551615 (i.e. -1).</para>
<para><varname>Capabilities</varname> contains the configured capabilities, as formatted with
<citerefentry project='man-pages'><refentrytitle>cap_to_text</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
</para>
<para><varname>SecureBits</varname>, <varname>CapabilityBoundingSet</varname>,
<varname>MountFlags</varname> also correspond to the configured settings of the unit files, but are
encoded as the actual binary flag fields they are, rather than formatted as string.</para>
<varname>MountFlags</varname> also correspond to the configured settings of the unit files, but
instead of being formatted as strings, they are encoded as the actual binary flags they are.
</para>
<para><varname>ExecMainStartTimestamp</varname>, <varname>ExecMainStartTimestampMonotonic</varname>,
<varname>ExecMainExitTimestamp</varname>, <varname>ExecMainExitTimestampMonotonic</varname>,
@ -1119,17 +1122,17 @@ $ gdbus introspect --system --dest org.freedesktop.systemd1 \
explanatory string.</para>
<para><varname>Result</varname> encodes the execution result of the last run of the service. It is
useful to determine the reason a service failed if it is in <literal>failed</literal> state (see
useful to determine the reason a service failed if it is in the <literal>failed</literal> state (see
<varname>ActiveState</varname> above). The following values are currently known:
<literal>success</literal> is set if the unit didn't fail. <literal>resources</literal> indicates that
not enough resources have been available to fork off and execute the service
not enough resources were available to fork off and execute the service
processes. <literal>timeout</literal> indicates that a time-out occurred while executing a service
operation. <literal>exit-code</literal> indicates that a service process exited with an unclean exit
code. <literal>signal</literal> indicates that a service process exited with an uncaught
signal. <literal>core-dump</literal> indicates that a service process exited uncleanly and dumped
core. <literal>watchdog</literal> indicates that a service did not send out watchdog ping messages
often enough. <literal>start-limit</literal> indicates that a service has been started too frequently
in a time frame (as configured in <varname>StartLimitInterval</varname>,
in a specific time frame (as configured in <varname>StartLimitInterval</varname>,
<varname>StartLimitBurst</varname>).</para>
<para><varname>ControlGroup</varname> indicates the control group path the processes of this service
@ -1292,15 +1295,15 @@ node /org/freedesktop/systemd1/unit/avahi_2ddaemon_2esocket {
i.e. those where systemd is responsible for accepted connections. </para>
<para>Similarly <varname>NConnections</varname> contains the number of currently open connections on
this socket, and also applies only to socket with <varname>Accept</varname> set to
this socket. It only applies only to socket units with <varname>Accept</varname> set to
<literal>true</literal>.</para>
<para><varname>Result</varname> encodes the reason why a socket unit failed if it is in
<para><varname>Result</varname> encodes the reason why a socket unit failed if it is in the
<literal>failed</literal> state (see <varname>ActiveState</varname> above). The values
<literal>success</literal>, <literal>resources</literal>, <literal>timeout</literal>,
<literal>exit-code</literal>, <literal>signal</literal> and <literal>core-dump</literal> have the same
meaning as they have for the corresponding field of service units (see above). In addition to that the
value <literal>service-failed-permanent</literal> indicates that the service of this socket failed
meaning as they have for the corresponding field of service units (see above). In addition to that,
the value <literal>service-failed-permanent</literal> indicates that the service of this socket failed
continuously.</para>
</refsect2>
</refsect1>
@ -1379,13 +1382,12 @@ node /org/freedesktop/systemd1/unit/dev_2d_foo_2edevice {
</refsect2>
</refsect1>
<refsect1>
<title>Mount Unit Objects</title>
<para>All mount unit objects implement the <interfacename>org.freedesktop.systemd1.Mount</interfacename>
interface (described here) in addition to the generic
<interfacename>org.freedesktop.systemd1.Unit</interfacename> interface (see above)</para>
<interfacename>org.freedesktop.systemd1.Unit</interfacename> interface (see above).</para>
<programlisting interface="org.freedesktop.systemd1.Mount">
$ gdbus introspect --system --dest org.freedesktop.systemd1 \
@ -1503,7 +1505,7 @@ node /org/freedesktop/systemd1/unit/home_2emount {
<title>Properties</title>
<para>Most of the properties map directly to the corresponding settings in mount unit files. As mount
units invoke the <filename>/usr/bin/mount</filename> command their bus objects include implicit
units invoke the <filename>/usr/bin/mount</filename> command, their bus objects include implicit
<varname>ExecMount</varname> (and similar) fields which contain information about processes to
execute. They also share most of the fields related to the execution context that Service objects
expose (see above). In addition to these properties there are the following:</para>
@ -1514,7 +1516,7 @@ node /org/freedesktop/systemd1/unit/home_2emount {
<para><varname>Result</varname> contains a value explaining why a mount unit failed if it failed. It
can take the values <literal>success</literal>, <literal>resources</literal>,
<literal>timeout</literal>, <literal>exit-code</literal>, <literal>signal</literal>,
<literal>timeout</literal>, <literal>exit-code</literal>, <literal>signal</literal>, or
<literal>core-dump</literal> which have the identical meaning as the corresponding values of the
corresponding field of service unit objects (see above).</para>
</refsect2>
@ -1562,7 +1564,7 @@ node /org/freedesktop/systemd1/unit/proc_2dsys_2dfs_2dbinfmt_5fmisc_2eautomount
files.</para>
<para><varname>Result</varname> knows the values <literal>success</literal> and
<literal>resources</literal>, at this time. They have the same meanings as the corresponding values of
<literal>resources</literal> at this time. They have the same meanings as the corresponding values of
the corresponding field of the Service object.</para>
</refsect2>
</refsect1>
@ -1611,10 +1613,10 @@ node /org/freedesktop/systemd1/unit/systemd_2dtmpfiles_2dclean_2etimer {
<para><varname>TimersMonotonic</varname> contains an array of structs that contain information about
all monotonic timers of this timer unit. The structs contain a string identifying the timer base, which
is one of <literal>OnActiveUSec</literal>, <literal>OnBootUSec</literal>,
<literal>OnStartupUSec</literal>, <literal>OnUnitActiveUSec</literal>,
<literal>OnUnitInactiveUSec</literal>, which correspond to the settings of the same names in the timer
<literal>OnStartupUSec</literal>, <literal>OnUnitActiveUSec</literal>, or
<literal>OnUnitInactiveUSec</literal> which correspond to the settings of the same names in the timer
unit files; the microsecond offset from this timer base in monotonic time; the next elapsation point on
the <constant>CLOCK_MONOTONIC</constant> clock, relative its epoch.</para>
the <constant>CLOCK_MONOTONIC</constant> clock, relative to its epoch.</para>
<para><varname>TimersCalendar</varname> contains an array of structs that contain information about all
realtime/calendar timers of this timer unit. The structs contain a string identifying the timer base,
@ -1757,7 +1759,7 @@ node /org/freedesktop/systemd1/unit/dev_2dsda3_2eswap {
<para>Most of the properties map directly to the corresponding settings in swap unit files. As mount
units invoke the
<citerefentry><refentrytitle>swapon</refentrytitle><manvolnum>8</manvolnum></citerefentry> command
<citerefentry><refentrytitle>swapon</refentrytitle><manvolnum>8</manvolnum></citerefentry> command,
their bus objects include implicit <varname>ExecActivate</varname> (and similar) fields which contain
information about processes to execute. They also share most of the fields related to the execution
context that Service objects expose (see above). In addition to these properties there are the
@ -1770,7 +1772,7 @@ node /org/freedesktop/systemd1/unit/dev_2dsda3_2eswap {
<para><varname>Result</varname> contains a value explaining why a mount unit failed if it failed. It
can take the values <literal>success</literal>, <literal>resources</literal>,
<literal>timeout</literal>, <literal>exit-code</literal>, <literal>signal</literal>,
<literal>timeout</literal>, <literal>exit-code</literal>, <literal>signal</literal>, or
<literal>core-dump</literal> which have the identical meanings as the corresponding values of the
corresponding field of service unit objects (see above).</para>
</refsect2>
@ -1819,12 +1821,12 @@ node /org/freedesktop/systemd1/unit/cups_2epath {
<para><varname>Paths</varname> contains an array of structs. Each struct contains the condition to
watch, which can be one of <literal>PathExists</literal>, <literal>PathExistsGlob</literal>,
<literal>PathChanged</literal>, <literal>PathModified</literal>, <literal>DirectoryNotEmpty</literal>
<literal>PathChanged</literal>, <literal>PathModified</literal>, or <literal>DirectoryNotEmpty</literal>
which correspond directly to the matching settings in the path unit files; and the path to watch,
possibly including glob expressions.</para>
<para><varname>Result</varname> contains a result value which can be <literal>success</literal> or
<literal>resources</literal>, which have the same meaning as the corresponding field of the service
<literal>resources</literal> which have the same meaning as the corresponding field of the Service
interface.</para>
</refsect2>
</refsect1>
@ -1942,7 +1944,7 @@ node /org/freedesktop/systemd1/unit/session_2d1_2escope {
<para><function>Abandon()</function> may be used to place a scope unit in the "abandoned" state. This
may be used to inform the system manager that the manager that created the scope lost interest in the
scope (for example, because it is terminating), without wanting to shut down the scope entirely</para>
scope (for example, because it is terminating), without wanting to shut down the scope entirely.</para>
</refsect2>
<refsect2>
@ -1950,18 +1952,18 @@ node /org/freedesktop/systemd1/unit/session_2d1_2escope {
<para><function>RequestStop</function> is sent to the peer that is configured in the
<varname>Controller</varname> property when systemd is requested to terminate the scope unit. A program
registering a scope can use this to cleanly shut down the processes it added to the scope, instead of
registering a scope can use this to cleanly shut down the processes it added to the scope instead of
letting systemd do it with the usual <constant>SIGTERM</constant> logic.</para>
</refsect2>
<refsect2>
<title>Properties</title>
<para>All properties correspond directly with the matching properties of service units</para>
<para>All properties correspond directly with the matching properties of service units.</para>
<para><varname>Controller</varname> contains the bus name (unique or well-known) that is notified when
the scope unit is to be shut down via a <function>RequestStop</function> signal (see below). This is
set when the scope is created. If not set the scope's processes will terminated with
set when the scope is created. If not set, the scope's processes will terminated with
<constant>SIGTERM</constant> directly.</para>
</refsect2>
</refsect1>
@ -2015,17 +2017,17 @@ node /org/freedesktop/systemd1/job/1292 {
<para><varname>Id</varname> is the numeric Id of the job. During the runtime of a systemd instance each
numeric ID is only assigned once.</para>
<para><varname>Unit</varname> refers to the unit this job belongs two. It is a structure consisting of
<para><varname>Unit</varname> refers to the unit this job belongs to. It is a structure consisting of
the name of the unit and a bus path to the unit's object.</para>
<para><varname>JobType</varname> refers to the job's type and is one of <literal>start</literal>,
<literal>verify-active</literal>, <literal>stop</literal>, <literal>reload</literal>,
<literal>restart</literal>, <literal>try-restart</literal>, <literal>reload-or-start</literal>. Note
<literal>restart</literal>, <literal>try-restart</literal>, or <literal>reload-or-start</literal>. Note
that later versions might define additional values.</para>
<para><varname>State</varname> refers to the job's state and is one of <literal>waiting</literal> and
<literal>running</literal>. The former indicates that a job is currently queued but has not begun to
execute yet, the latter indicates that a job is currently being executed.</para>
execute yet. The latter indicates that a job is currently being executed.</para>
</refsect2>
</refsect1>