verify: use manager_load_startable_unit_or_warn() to load units for verification

[thirdparty/systemd.git] / man / file-hierarchy.xml

diff --git a/man/file-hierarchy.xml b/man/file-hierarchy.xml
index 9a1791cd17d820be87178abfac8bb39edc211c64..3e28fc6beebea86248c6d6c3c0d8d4b786632566 100644 (file)
--- a/man/file-hierarchy.xml
+++ b/man/file-hierarchy.xml
@@ -57,7 +57,7 @@
     system and service manager are organized based on a file system
     hierarchy inspired by UNIX, more specifically the hierarchy
     described in the <ulink
-    url="http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html">File
+    url="http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html">File
     System Hierarchy</ulink> specification and
     <citerefentry project='man-pages'><refentrytitle>hier</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
     This manual page describes a more minimal, modernized subset of
@@ -694,7 +694,7 @@
           </row>
           <row>
       <entry><filename>/run/<replaceable>package</replaceable></filename></entry>
-      <entry>Runtime data for the package. Packages must be able to create the necessary subdirectories in this tree on their own, since the directory is flushed automatically on boot. Alternatively, a <citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> fragment may be used to create the necessary directories during boot. Alternatively, the <varname>RuntimeDirectory=</varname> directive of service units may be used (see <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> for details).</entry>
+      <entry>Runtime data for the package. Packages must be able to create the necessary subdirectories in this tree on their own, since the directory is flushed automatically on boot. Alternatively, a <citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> fragment may be used to create the necessary directories during boot, or the <varname>RuntimeDirectory=</varname> directive of service units may be used to create them at service startup (see <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> for details).</entry>
           </row>
           <row>
       <entry><filename>/run/log/<replaceable>package</replaceable></filename></entry>
@@ -702,15 +702,15 @@
           </row>
           <row>
       <entry><filename>/var/cache/<replaceable>package</replaceable></filename></entry>
-      <entry>Persistent cache data of the package. If this directory is flushed, the application should work correctly on next invocation, though possibly slowed down due to the need to rebuild any local cache files. The application must be capable of recreating this directory should it be missing and necessary.</entry>
+      <entry>Persistent cache data of the package. If this directory is flushed, the application should work correctly on next invocation, though possibly slowed down due to the need to rebuild any local cache files. The application must be capable of recreating this directory should it be missing and necessary. To create an empty directory, a <citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> fragment or the <varname>CacheDirectory=</varname> directive of service units (see <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>) may be used.</entry>
           </row>
           <row>
       <entry><filename>/var/lib/<replaceable>package</replaceable></filename></entry>
-      <entry>Persistent private data of the package. This is the primary place to put persistent data that does not fall into the other categories listed. Packages should be able to create the necessary subdirectories in this tree on their own, since the directory might be missing on boot. Alternatively, a <citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> fragment may be used to create the necessary directories during boot. Alternatively, the <varname>StateDirectory=</varname> directive of service units may be used (see <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> for details).</entry>
+      <entry>Persistent private data of the package. This is the primary place to put persistent data that does not fall into the other categories listed. Packages should be able to create the necessary subdirectories in this tree on their own, since the directory might be missing on boot. To create an empty directory, a <citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> fragment or the <varname>StateDirectory=</varname> directive of service units (see <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>) may be used.</entry>
           </row>
           <row>
       <entry><filename>/var/log/<replaceable>package</replaceable></filename></entry>
-      <entry>Persistent log data of the package. As above, the package should make sure to create this directory if necessary, as it might be missing.</entry>
+      <entry>Persistent log data of the package. As above, the package should make sure to create this directory if necessary, possibly using <citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> or <varname>LogsDirectory=</varname> (see <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>), as it might be missing.</entry>
           </row>
           <row>
       <entry><filename>/var/spool/<replaceable>package</replaceable></filename></entry>