There are sometimes users who put unit files in a location that is inaccessible
when systemd starts although they are not found and thus not started because
the corresponding mount units have not activated yet.
There is already a warning for such issue in man 8 systemctl:
link PATH...
...<snip>...
The file system where
the linked unit files are located must be accessible
when systemd is started (e.g. anything underneath /home
or /var is not allowed, unless those directories are
located on the root file system).
However, it looks that it's difficult to find the warning because introductory
users typically doesn't know systemctl link.
Although there is a description in UNIT FILE LOAD PATH pointing to systemctl
link, symlink is now not explicitly mentioned there and thus users doesn't
easily get aware of they should read it.
To deal with this, let's describe "symlink" and "systemctl link" more
explicitly in UNIT FILE LOAD PATH.
<programlisting>systemd-analyze --user unit-paths</programlisting>
</para>
- <para>Moreover, additional units might be loaded into systemd ("linked") from
- directories not on the unit load path. See the <command>link</command> command
- for
- <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+ <para>Moreover, additional units might be loaded into systemd from
+ directories not on the unit load path by creating a symlink pointing to a
+ unit file in the directories. You can use <command>systemctl link</command>
+ for this operation. See
+ <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+ for its usage and precaution.
</para>
</refsect1>
projects / thirdparty / systemd.git / commitdiff
