By default, in instances where timers are running on a realtime schedule,
if a service takes longer to run than the interval of a timer, the
service will immediately start again when the previous invocation finishes.
This is caused by the fact that the next elapse is calculated based on
the last trigger time, which, combined with the fact that the interval
is shorter than the runtime of the service, causes that elapse to be in
the past, which in turn means the timer will trigger as soon as the
service finishes running.
This behavior can be changed by enabling the new DeferReactivation setting,
which will cause the next calendar elapse to be calculated based on when
the trigger unit enters inactivity, rather than the last trigger time.
Thus, if a timer is on an realtime interval, the trigger will always
adhere to that specified interval.
E.g. if you have a timer that runs on a minutely interval, the setting
guarantees that triggers will happen at *:*:00 times, whereas by default
this may skew depending on how long the service runs.
Co-authored-by: Matteo Croce <teknoraver@meta.com>
This is a new syscall provided by the kernel used to implement faster
uprobes. It's not supposed to be called by userspace, but only by kernel
generated uprobe code.
It should be fine to allow this, as the kernel authenticates the
invocation itself, and we shouldn't break compat with things.
Note that this allowlisting is not sufficient to make ureprobe() work.
libseccomp must be tought the syscall too, but this can happen
independently.
Fixes: #34615
Let's move this check to bus_connect_transport_systemd() so that
bus_connect_system_systemd() will only ever connect to the manager
private manager bus instance and fail otherwise.
We have various callsites that explicitly need the manager bus and
won't work with the system bus, like daemon-reexec and friends which
can't properly wait until the operation has finished unless using the
manager bus.
If we silently fall back to the system bus for these operations, we
can end up with rather hard to debug issues so let's remove the fallback
as it was added back in 2013 in a6aa89122d
without a clear explanation of why it was needed (I expect as a fallback
if kdbus wasn't available but that's not a thing anymore these days).
Some structures we'll use in various varlink interfaces, move them to a
common .c/.h file. For now this is only the dual timestamp object, but
there will be more soon.
Preparation for later commits, where path-lookup would be
moved into libsystemd.
Note that it currently includes sd-id128.h, hence shared/
seems more appropriate anyway.
Let's mark functions that accept the 'more' flag explicitly for that,
and validate for this explicitly.
This is preparation for
https://github.com/varlink/varlink.github.io/issues/26, if we get that
one day. Let's make sure that from day #1 we have this info available
even if we don't generate this in the IDL for now.
Also enables the two flags for all interfaces we export that use the
logic.
Let's systematically use RTL_NOW|RLTD_NODELETE as flags passed to
dlopen(), across our codebase.
Various distros build with "-z now" anyway, hence it's weird to specify
RTLD_LAZY trying to override that (which it doesn't). Hence, let's
follow suit, and just do what everybody else does.
Also set RTLD_NODELETE, which is apparently what distros will probably
end up implying sooner or later anyway. Given that for pretty much all
our dlopen() calls we never call dlclose() anyway, let's just set this
everywhere too, to make things systematic.
This way, the flags we use by default match what distros such as fedora
do, there are no surprises, and read-only relocations can be a thing.
Fixes: #34537
After 3b16e9f419, even the libraries are
documented in the man page, it is useful to mention which libraries are
checked in the command output.
Of course, the dependencies are kind of implementation detail, and may
be changed in the future version, but that's especially why I think
showing the library deps in the output is useful.
systemd-analyze is a debugging tool, and already shows many internal
states. I think there is nothing to prevent from showing the deps.
Prompted by #34477.