This patch adds more detail to the description of how path escaping
operates and provides a pointer to the systemd-escape program. Either
would serve to answer the question raised in the bug report, so
hopefully this will allow it to be closed.
https://bugs.freedesktop.org/show_bug.cgi?id=87688
(cherry picked from commit 995084c7b4)
The reasons were already given in the description of %U, but the
are easy to overlook, and it's better to be explicit to avoid
confusion.
(cherry picked from commit b7a4d8de92)
Since the manpage already talks about shell-compatibility, it should be
more accurate about what needs to be escaped and how.
(cherry picked from commit 321a3f5133)
In man journald.conf, removes reference to XZ as sole form of
compression. See commit d89c8fdf48.
In man coredump.conf, clarifies that "Compression=" controls existence,
not type, of compression.
(cherry picked from commit 442f7f1553)
In principle SysV stuff is only for compatibility, but we are stuck
with it for the forseeable future, so documentation might as well
be provided.
https://bugs.debian.org/771172
(cherry picked from commit f509443af5)
systemd stops adding automatic dependencies on swap.target to swap
units. If a dependency is required, it has to be added by unit
configuration. fstab-generator did that already, except that now it is
modified to create a Requires or Wants type dependency, depending on
whether nofail is specified in /etc/fstab. This makes .swap units
obey the nofail/noauto options more or less the same as .mount units.
Documentation is extended to clarify that, and to make
systemd.mount(5) and system.swap(5) more similar. The gist is not
changed, because current behaviour actually matches existing
documentation.
https://bugs.freedesktop.org/show_bug.cgi?id=86488
(cherry picked from commit 5607d856b8)
The previous version was a bit too vague. It is better
to simply list all dependency types that are followed.
Previous version also made an emphasis on dependencies introduced by
configuration. But this command (or systemd) don't care about this
distinction between configured and automatically added dependencies at
all. This distinctionis removed from the main description, and an
explanatory paragraph is added to remind the user that all
dependencies are shown, no matter where they come from.
(cherry picked from commit f6375e8376)
This effectively reverts 599b6322f1, which
in turn partially reverted 4dc5b821ae.
The --failed switch is not documented on purpose, since it is redundant
due to --state=failed, which it predates. Due to that it's not
documented in --help either.
We generally try to avoid redundant interfaces, but if we need to keep
them for compatibility we do so, however remove them from documentation
to ensure they are not used in future.
The man page is now changed to include a comment about the fact that
--failed is not documented on purpose. Also, explicitly mention
--state=failed as example for --state.
(cherry picked from commit 036359ba8d)
We really don't want to get lost in adding fridge, car, plane, drone, or
whatever else, hence add a generic term "embedded" cover all the cases
where the computer is just part of something bigger, and not at the
focus of things.
(cherry picked from commit 25fa306ed5)
For now, it's systemd itself that parses the options string, but as soon
as util-linux' swapon can take the option string directly with -o we
should pass it on unmodified.
In some cases it is preferable to ship system images with a pre-generated
binary hwdb database, to avoid having to build it at runtime, avoid shipping
the source hwdb files, or avoid storing large binary files in /etc.
So if hwdb.bin does not exist in /etc/udev/, fall back to looking for it in
UDEVLIBEXECDIR. This keeps the possibility to add files to /etc/udev/hwdb.d/
and re-generating the database which trumps the one in /usr/lib.
Add a new --usr flag to "udevadm hwdb --update" which puts the database
into UDEVLIBEXECDIR.
Adjust systemd-udev-hwdb-update.service to not generate the file in /etc if we
already have it in /usr.
The system start timeout as previously implemented would get confused by
long-running services that are included in the initial system startup
transaction for example by being cron-job-like long-running services
triggered immediately at boot. Such long-running jobs would be subject
to the default 15min timeout, esily triggering it.
Hence, remove this again. In a subsequent commit, introduce per-target
job timeouts instead, that allow us to control these timeouts more
finegrained.
Zbigniew Jędrzejewski-Szmek