to make it easier to figure out why it fails.
For example in https://github.com/systemd/systemd/runs/4799774735?check_suite_focus=true
it failed with
```
meson.build:1003:8: ERROR: Command "/usr/bin/clang -print-targets" failed with status 1.
A full log can be found at /home/runner/work/systemd/systemd/build/meson-logs/meson-log.txt
Error: Process completed with exit code 1.
```
and it wasn't clear what exactly happened there.
If a desktop specific ExecCondition= binary does not exist, this just
means that the desktop environment is not available. As such, it is not
an error condition that should prevent the service from being installed
in the .wants target.
Fix this by simply returning zero.
All those pages contain a redirect at the top of the page, so it doesn't
make much sense to tell people to take the detour. Linking directly will
also increase the search rankings of the new pages.
The file has instructions how to "enable" it by symlinking into the
appropriate place. If we create a different mechanism to do enablement
later on, we can always adjust the instructions.
Closes#3998.
Same justification as the previous commit.
$ for i in network/*-*; do git blame $i;done | less
shows that those files were written by Tom Gundersen, Lennart Poettering, Yu
Watanabe, me, and Marc-André Lureau.
This matches what we have for example programs under man/, and is nice
because it allows people to copy the files as they wish without worrying
about copyright. The files are too trivial to copyright anyway.
The systemd-oomd.service unit contains
[Install]
WantedBy=multi-user.target
Alias=dbus-org.freedesktop.oom1.service
which means the symlink is supposed to be created dynamically when the
service is enabled.
No need to invoke ls when we are just interested in file names.
Also, the cd to source root makes the output identical to
"git ls-files" (relative instead of absolute paths).
log_parse_environment() uses should_parse_proc_cmdline() to determine whether
it should parse settings from the kernel command line. But the checks that
should_parse_proc_cmdline() apply to the whole process, and we could get a positive
answer also when log_parse_environment() was called from one of the nss modules.
In case of nss-modules, we don't want to look at the kernel command line.
log_parse_environment_variables() that only looks at the environment variables
is split out and used in the nss modules.
Fixes#22020.
* sd-bus/man: document EBUSY error in bus_message_read
The EBUSY error can be returned from sd_bus_exit_container(), and, if
that happens, it will be propogated upwards towards bus_message_read. In
terms of documentation, this means that bus_message_read's man page
can't just include the error text for sd_bus_message_read_basic, as
reading basic types exclusively doesn't have the potential for this
error.
sd_bus_message_read_basic's error documentation isn't incorrect when
applied to sd_bus_message_read, it's just incomplete. While EBUSY is
documented in sd_bus_message_open_container.xml,
it's explanation is unique to the sd_bus_message_exit_container function
and makes for poor documentation of the general read API.
There are a few undesirable properties to how boot entries are
currently sorted.
First, it sorts by entry file name only, which may not correspond
to the title that is shown (for exmaple because it is prefixed by
machine-id). The file ending will also create unexpected ordering
("arch-lts.conf" would come before "arch.conf").
While the list is sorted alphabetically ascending, it is also
lower version/priority first, which is unintuitive. In particular,
a boot-counted entry that is bad (0 tries left) will be at the very
top.
Additionally, the Windows and Mac loaders should be sorted with
the rest of the loaders.
The BFQ weights are not passed verbatim to the kernel, provide that
information in a form of debug message so that users are not
surprised/confused when IOWeight != io.bfq.weight.