The emergency.service and rescue.service units have become rather
convoluted. We spawn multiple shells and the help text spans multiple lines
which makes the units hard to read.
Move the logic into a single shell script and call that via ExecStart.
Previously, `SO_REUSEADDR` is set before `bind`-ing socket, Thus,
even if another LLMNR stack is running, `bind` always success and
we cannot detect the other stack. By this commit, we first try to
`bind` without `SO_REUSEADDR`, and if it fails, show warning and
retry with `SO_REUSEADDR`.
Previously, `SO_REUSEADDR` is set before `bind`-ing socket, Thus,
even if another mDNS stack (e.g. avahi) is running, `bind` always
success and we cannot detect the other stack.
By this commit, we first try to `bind` without `SO_REUSEADDR`,
and if it fails, show warning and retry with `SO_REUSEADDR`.
When no network enables LLMNR or mDNS, it is not necessary to create
LLMNR or mDNS related sockets. So, let's create them only when
LLMNR- or mDNS-enabled network becomes active or at least one network
enables `LLMNR=` or `MulticastDNS=` options.
Per man:file-hierarchy(7), /lib is just a compatibility symlink; the
other manpages also refer to /usr/lib.
Found with:
git grep -P '(?<!/usr|/var|local)/lib' man/
Ideally, plymouth should only be referenced via dependencies,
not ExecStartPre's. This at least avoids the confusing error message
on minimal installations that do not carry plymouth.
If we are working on a path that was marked to be ignored on errors, and
the mkdirat() fails then add a continue statement and skip fchownat() call.
This avoids the case where UID/GID are valid and we run fchownat() on
non existent path which will fail hard even on paths that we want to
ignore in case of errors.
When mmap is called, the code in correctly checks for p == MAP_FAILED.
But the resource cleanup at the end of busname_peek_message checks for
p == NULL, and if that's not true, munmap is called.
Therefore in error case, munmap is called with a MAP_FAILED argument
which can result in unexpected behaviour depending on sz's value.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
It is possible to overflow uint64_t while validating the header of
a journal file. To prevent this, the addition itself is checked to
be within the limits of UINT64_MAX first.
To keep this readable, I have introduced two stack variables which
hold the converted values during validation.
