tmpfiles: remove old ICE and X11 sockets at boot
When not using tmpfs based /tmp, leftover sockets
might prevent X startup. Ensure directory is clean at boot time.
This change noticeably increases completion performance at the expense
of preventing possible _correct, _approximate or any matcher-list rules.
Still, responsiveness increase so huge seems to make it worth the price.
This adds "systemd-resolve --reset-server-features" for explicitly
forgetting what we learnt. This might be useful for debugging
purposes, and to force systemd-resolved to restart its learning logic
for all DNS servers.
When the network configuration changes we should relearn everything
there is to know about the configured DNS servers, because we might talk
to the same addresses, but there might be different servers behind them.
After the discussions around #7003 I think we should restore the
User=systemd-journal-gateway line for systemd-journal-gatewayd.service,
too, so that we continue to use the state user if it exists, and create
it as dynamic user only when it does not.
Note that undoes part of a change made after 234, i.e. a never released
change.
The gettid syscall is one of the most basic syscalls, it never fails and
it operates on current thread. Most applications are not suposed to use
it, however even if it is used there is no much justification on blocking
it. This patch removes it from '@process' set so if users blacklist this
set to block setns or clone syscalls, the gettid syscall will still be
available. Of course they can always block gettid explicitly.
Note that the gettid is already in the '@default' set.
We added JobRunningTimeoutSec= late, and Dracut configured only
JobTimeoutSec= to turn of root device timeouts before. With this change
we'll propagate a reset of JobTimeoutSec= into JobRunningTimeoutSec=,
but only if the latter wasn't set explicitly.
This should restore compatibility with older systemd versions.
Fixes: #6402
When we a reply message gets longer than the client supports we need to
truncate the response and set the TC bit, and we already do that.
However, we are not supposed to send incomplete RRs in that case, but
instead truncate right at a record boundary. Do that.
This fixes the "Message parser reports malformed message packet."
warning the venerable "host" tool outputs when a very large response is
requested.
See: #6520
System calls might exist on some archs but not on others, or might be
multiplexed but not on others. Ignore such errors when putting together
a filter at this location like we already do it on all others.
Unfortunately libseccomp doesn't return (nor document) clean error
codes, hence until then only check for specific error codes that we
propagate, but ignore (but debug log) all others. Do this at one more
place, we are already doing that at all others.
When a libseccomp implementation doesn't know a syscall yet, that's no
reason for us to fail completely. Instead, debug log, and proceed.
This hopefully fixes the preadv2/pwritev2 issues pointed out here:
https://github.com/systemd/systemd/pull/6952#issuecomment-334302923
Also, move prlimit64() out of @resources.
prlimit64() may be used both for getting and setting resource limits, and
is implicitly called by glibc at various places, on some archs, the same
was as getrlimit(). SImilar, igetrlimit() is an arch-specific
replacement for getrlimit(), and hence should be whitelisted at the same
place as getrlimit() and prlimit64().
Also see: https://lists.freedesktop.org/archives/systemd-devel/2017-September/039543.html
This fixes a mostly theoretical potential security hole: if for some
reason we failed to remove IPC objects created for a dynamic user (maybe
because a MAC/SElinux erronously prohibited), then we should not hand
out the same UID again until they are successfully removed.
With this commit we'll enumerate the IPC objects currently existing, and
step away from using a UID for the dynamic UID logic if there are any
matching it.
This documents the status quo, clarifying when we are synchronous and
when asynchronous by default and when --no-block is support to force
asynchronous operation.
See: #6479
Currently, "systemctl reboot" behaves differently in setups with and
without logind. If logind is used (which is probably the more common
case) the operation is asynchronous, and otherwise synchronous (though
subject to --no-block in this case). Let's clean this up, and always
expose the same behaviour, regardless if logind is used or not: let's
always make it asynchronous.
It might make sense to add a "--block" mode in a future PR that makes
these operations synchronous, but this requires non-trivial work in
logind, and is outside of the scope of this change.
See: #6479
This adds new method calls Halt() and CanHalt() to the logind bus APIs.
They aren't overly useful (as the whole concept of halting isn't really
too useful), however they clean up one major asymmetry: currently, using
the "shutdown" legacy commands it is possibly to enqueue a "halt"
operation through logind, while logind officially doesn't actually
support this. Moreover, the path through "shutdown" currently ultimately
fails, since the referenced "halt" action isn't actually defined in
PolicyKit.
Finally, the current logic results in an unexpected asymmetry in
systemctl: "systemctl poweroff", "systemctl reboot" are currently
asynchronous (due to the logind involvement) while "systemctl halt"
isnt. Let's clean this up, and make all three APIs implemented by
logind natively, and all three hence asynchronous in "systemctl".
Moreover, let's add the missing PK action.
Fixes: #6957
STR_IN_SET is a newer approach which is easier to write and read, and which
seems to result in space savings too:
before:
4949848 build/src/shared/libsystemd-shared-234.so
350704 build/systemctl
4967184 build/systemd
826216 build/udevadm
after:
4949848 build/src/shared/libsystemd-shared-234.so
350704 build/systemctl
4966888 build/systemd
826168 build/udevadm
Yu Watanabe