From cce68ffed8c40fc2eb2e1a29fa8e48585377510f Mon Sep 17 00:00:00 2001 From: Daniel Golle Date: Sun, 20 Sep 2026 20:03:08 +0100 Subject: [PATCH 1/2] validation/start: require the process unset error The test asserts that `start` succeeds on a container created without a `process`, while the requirement it reports under is the opposite one: runtime.md says the operation MUST generate an error if `process` was not set, and the command line interface requires a non-zero exit code on errors. A runtime that refuses the start is marked as failing, and one that quietly returns success passes. Expect the error. The container is then left in whichever state the runtime chose, and neither document says how to dispose of a container that has no `process` to signal, so clean up without asserting on the way out. Signed-off-by: Daniel Golle --- validation/start/start.go | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/validation/start/start.go b/validation/start/start.go index 07895d8e..656cb02c 100644 --- a/validation/start/start.go +++ b/validation/start/start.go @@ -109,12 +109,10 @@ func main() { } err = r.Start() - util.SpecErrorOK(t, err == nil, specerror.NewError(specerror.StartWithProcUnsetGenError, fmt.Errorf("`start` operation MUST generate an error if `process` was not set"), rspecs.Version), err) - err = util.WaitingForStatus(r, util.LifecycleStatusStopped, time.Second*10, time.Second*1) - if err == nil { - err = r.Delete() - } - if err != nil { - t.Fail(err.Error()) - } + util.SpecErrorOK(t, err != nil, specerror.NewError(specerror.StartWithProcUnsetGenError, fmt.Errorf("`start` operation MUST generate an error if `process` was not set"), rspecs.Version), err) + + // The container never ran, and nothing in the spec says how to dispose + // of one that has no `process` to signal, so tear it down without + // holding the runtime to a particular way out. + r.Clean() } From 39eda9dca68bc12094b77d7ef8532a36f0d9d5b2 Mon Sep 17 00:00:00 2001 From: Daniel Golle Date: Sun, 20 Sep 2026 20:03:15 +0100 Subject: [PATCH 2/2] validation/pidfile: do not kill a stopped container The container runs `true`, so it has already exited by the time the test tears it down. The teardown waits for it to be `running`, ignores the timeout it gets instead, kills it anyway and then reports the kill error as the result of the pid file check. Signalling a container that is neither `created` nor `running` MUST generate an error, so every runtime that gets that right fails a test about `--pid-file`. This is also the assertion kill.t case four makes, and no runtime could satisfy both. Wait for the process to exit on its own instead, which is all the teardown needs. Fixes #805 Signed-off-by: Daniel Golle --- validation/pidfile/pidfile.go | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/validation/pidfile/pidfile.go b/validation/pidfile/pidfile.go index 45adfbca..598f3e2c 100644 --- a/validation/pidfile/pidfile.go +++ b/validation/pidfile/pidfile.go @@ -56,11 +56,10 @@ func main() { return nil }, PreDelete: func(r *util.Runtime) error { - util.WaitingForStatus(*r, util.LifecycleStatusRunning, time.Second*10, time.Second*1) - err = r.Kill("KILL") - // wait before the container been deleted - util.WaitingForStatus(*r, util.LifecycleStatusStopped, time.Second*10, time.Second*1) - return err + // The container process is `true`, so it exits on its own and + // signalling it afterwards is an error the runtime is required + // to generate. + return util.WaitingForStatus(*r, util.LifecycleStatusStopped, time.Second*10, time.Second*1) }, }