Skip to content

Commit 5d5dbe6

Browse files
rajathagasthyanvidia-backport-bot
authored andcommitted
Start hook-managed services with --no-block to avoid deadlocks
The apply-exit hook starts nvsm and dcgm synchronously. These services are Wants=/After=nvidia-gpu-reset.target while nvidia-mig-manager.service runs Before= that target, so whenever the target is not yet active the requested start queues behind the service's own start job and the hook waits on a job that is waiting for the hook to finish: a deadlock. The earlier fix used --no-block only while the system was starting up, which covered boot but not package installation (or any other start while the target is inactive), where a package scriptlet starting nvsm pulls the whole chain into one transaction and hangs the install. Enqueue all service starts from hooks with --no-block unconditionally, including the k8s services in case any of them gains an ordering on the target. The hooks no longer wait on systemd jobs at all, so no ordering cycle can block them in any system state. The trade-off is that the hooks only report enqueue errors; service startup failures are reported by the started units themselves. Stops remain synchronous: the apply must not proceed until GPU clients are actually gone. Signed-off-by: Rajath Agasthya <ragasthya@nvidia.com> (cherry picked from commit 92c9110)
1 parent 06375d7 commit 5d5dbe6

1 file changed

Lines changed: 14 additions & 16 deletions

File tree

deployments/systemd/hooks.sh

Lines changed: 14 additions & 16 deletions
Original file line numberDiff line numberDiff line change
@@ -92,21 +92,16 @@ function stop_driver_services() {
9292
}
9393

9494
function start_driver_services() {
95-
# Driver services are ordered After=nvidia-gpu-reset.target, and this
96-
# service runs Before that target. During boot, starting them
97-
# synchronously here deadlocks: this service waits on them while the
98-
# target (and therefore those services) waits on this service to finish.
99-
# While the system is still starting up, enqueue the start without
100-
# waiting; systemd starts them once this service completes and the target
101-
# is reached. Once the system is running, start synchronously as before so
102-
# a runtime reconfigure still waits for the services and reports failures.
103-
local start_args=""
104-
local state
105-
state="$(systemctl is-system-running 2>/dev/null)"
106-
if [ "${state}" != "running" ] && [ "${state}" != "degraded" ]; then
107-
start_args="--no-block"
108-
fi
109-
nvidia-mig-manager::service::start_systemd_services driver_services "${start_args}"
95+
# Driver services are Wants=/After=nvidia-gpu-reset.target and this
96+
# service runs Before= that target, so a synchronous start from this hook
97+
# can wait on a job that is itself waiting for this service to finish.
98+
# This happens whenever the target is not yet active: during boot, during
99+
# package installation, or on the first start after install. Never wait:
100+
# enqueue the start and return; systemd runs the queued starts once this
101+
# service completes and the target activates. Startup failures are
102+
# reported by the started units themselves, not by this hook; a non-zero
103+
# return here means systemd refused to enqueue the request.
104+
nvidia-mig-manager::service::start_systemd_services driver_services "--no-block"
110105
return ${?}
111106
}
112107

@@ -120,7 +115,10 @@ function stop_k8s_services() {
120115
}
121116

122117
function start_k8s_services() {
123-
nvidia-mig-manager::service::start_systemd_services k8s_services
118+
# Same policy as start_driver_services: never wait on a systemd job from
119+
# inside this hook, in case any of these units is ordered (directly or
120+
# transitively) after nvidia-gpu-reset.target.
121+
nvidia-mig-manager::service::start_systemd_services k8s_services "--no-block"
124122
return ${?}
125123
}
126124

0 commit comments

Comments
 (0)