Suppose a service has WatchdogSec set to 2 seconds in its unit file. I
then start the service and WatchdogUSec is set correctly:
% systemctl --user show psi-notify -p WatchdogUSec
WatchdogUSec=2s
Now I call `sd_notify(0, "WATCHDOG_USEC=10000000")`. The new timer seems
to have taken effect, since I only send `WATCHDOG=1` every 4 seconds,
and systemd isn't triggering the watchdog handler. However, `systemctl
show` still shows WatchdogUSec as 2s:
% systemctl --user show psi-notify -p WatchdogUSec
WatchdogUSec=2s
This seems surprising, since this "original" watchdog timer isn't the
one taking effect any more. This patch makes it so that we instead
display the new watchdog timer after sd_notify(WATCHDOG_USEC):
% systemctl --user show psi-notify -p WatchdogUSec
WatchdogUSec=10s
Fixes#15726.
Let's create new images public by default and then symlink/copy them
into the respective private directories afterwards, not the other way
around. This should fix a nasty race condition in parallel runs where
one tests attempts to copy the backing public image at the same moment
another test is already modifying it.
We want to watch USB sticks being plugged in, and that requires
AF_NETLINK to work correctly and get the host's events. But if we live
in a network namespace AF_NETLINK is disconnected too and we'll not get
the host udev events.
Fixes: #15287
This reverts commit 61c3e2c8bf.
The original commit doesn't make sense to me, none of the listed units
have an [Install] section, they hence are not subject to enable/disable
and hence not preset either. This commit hence has no effect whatsoever,
let's undo it to avoid further confusion.
Resolved can't reliably determine on whether "it makes sense" to query
AAAA records when not explicitly specifying it in the request, so we
shouldn't remove them.
After having done the resolving, applications can use RFC6724 to
determine whether that address is reachable.
We can't know whether an address is reachable before having resolved it
and inspecting the routing table, and not resolving AAAA just because
there's no IPv6 default route on the main interface link them breaks
various setups, including IPv6-providing wireguard tunnels on a
non-dualstacked environment.
Fixes#5782Fixes#5915Fixes#8017
We'd start writing an entry line, then another one, then another one,
and then output the rest of the first one, and then some other random
stuff, and the rest of some other lines... Results were ...eh... random.
Let's define a helper to avoid some of the copy&paste madness, and separate
blocks that output a single line with /**********************************/.
This rework doesn't change what data is written, it only tries to fix the
format of the output. The fact that some entries only write data from
link->network, and some from either link->network or link, some stuff only
for dhpc4 leases while some for both dhpc4 and dhcp6, etc, looks rather
suspicious too, but I didn't touch this.
We would print the error sometimes to stdout and sometimes to stderr. It *is*
useful to get the message if one of the names is not found on the bus to
stdout, so that this shows out in the pager. So let's do verification of args
early to catch invalid arguments, and then if we receive an error over the bus
(most likely that the name is not activatable), let's print to stdout so it
gets paged. E.g. 'busctl tree org.freedesktop.systemd1 org.freedesktop.systemd2'
gives a nicely usable output.
Users might want to use that to unset a previous setting. The docs seem OK as
they are: we don't need to explictly mention the empty value, since it is
almost always allowed.
Those fields are both uint32_t, so we should use the same type when parsing.
Having a different type didn't change the result, but let's be consistent.
Each of bus_set_address_{user,system} had two users, and each of the two users
would set the internal flag manually. We should do that internally in the
functions instead.
While at it, only set the flag when setting the address is actually successful.
This doesn't change anything for current users, but it seems more correct.