Now that we track auto-restarts with a dedicated state,
there's no need for a separate variable for this.
I also took the chance to reorder some struct members.
unit_start() advertises that start requests don't get suppressed,
so that it could be used to manually speed up auto restarts.
However, service_start() so far rejected this, stating that
clients should issue restart request in order to trigger
BindsTo=/OnFailure=.
That seems to be a red herring though, because for a long time
the service states between auto-restarts were buggy (#27594).
With the introduction of RestartMode=direct, the behavior
is sane again and customizable, hence I see no reason to refuse
this anymore. Whether those deps are triggered solely depends
on RestartMode= now.
Plus, filter out some intermediate states that should never
be seen in service_start().
Fixes#33890
Even if the glob pattern is valid, the pattern may match credentials
with invalid names. So, we need to check the names of the found
credentials.
Follow-up for 947c4d3952.
The s390x platform provides confidential VMs using the "Secure Execution"
technology, which is also referred to as "Protected Virtualization" or
just "prot virt" in Linux / QEMU.
This can be detected through a simple sysfs attribute.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We have different impls of detect_confidential_virtualization per
architecture. The detection is cached in the x86_64 impl, and as we
add support for more targets, we want to use caching for all. It thus
makes sense to split caching out into an architecture independent
method.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
cg_kill_kernel_sigkill() has a narrow use case, and currently
no code really reaches that branch. Let's detach it from
cg_kill_recursive() hence, and call it explicitly later
where appropriate.
When removing a cgroup, we always want to eliminate subcgroups
first, i.e. use cg_trim(). And cg_rmdir() (along with
CGROUP_REMOVE flag) is simply unused. Kill it.
tcp reset / icmp port-unreachable are markedly different conditions than
packet loss. It doesn't make much sense to retry in this case. It's
actually not clear if there is any benefit at all retrying tcp
connections, which were presumably already retried as necessary by the
tcp stack.
To make it work without sd-event.
Prompted by recent chat:
> Hey all!
> reading man libudev, it says to use sd-device instead now. I've read that
> APIs header file and it seems it no longer has an equivalent to libudev's
> udev_monitor_get_fd, which AFAICT means I have to use sd-event to watch
> for events I'm interested in. I know I can "embed" sd-event in other event
> loops I might already have, but that seems overkill when I'm only interested
> in this one type of event and don't need sd-event for anything else.
Previously, the main process of systemd-udevd manages worker process
with their sd_device_monitor object to save the destination address.
Let's save only destination address, and drop worker's sd_device_monitor
object.
Luca Boccassi
Yu Watanabe
Mike Yuan
Daniel P. Berrangé
jauge-technica
Ronan Pigott