Add --pidfile flag to podman start#28983
Open
nomarek wants to merge 4 commits into
Open
Conversation
create and run already take --pidfile, but the path is fixed at create time and reused on every start. Toolbx wants a fresh path per start so it can read the PID of the container's main process and wait on it before running podman exec. Add the same flag to start. Once the container is running we read its PID with Container.PID() and write it to the requested path. It only works for a single container, is rejected together with --attach, and is hidden on the remote client, the same as create and run. Fixes: podman-container-tools#25849 Signed-off-by: Marek Nogacki <no.marek@gmail.com>
The existing multi-container test only hits the client-side check in validateStart. Add an e2e case where --filter matches two containers so the guard in ContainerStart is exercised too. Also note in the man page that, unlike create and run, start does not store the pidfile path in the container config, and drop a test comment that just restated the assertion. Signed-off-by: Marek Nogacki <no.marek@gmail.com>
Two corner cases were handled wrong. An already-running container takes the idempotent ErrCtrStateRunning branch and returned before the pidfile was written, so start --pidfile produced no file at all. Honor --pidfile there too. An entry point that exits between Start() and the PID read makes PID() return 0 with no error, so we wrote a bogus "0" and reported success. Reject pid == 0 with an error instead. The pidfile write now lives in a small helper shared by both paths, and a new e2e test covers the already-running case. Signed-off-by: Marek Nogacki <no.marek@gmail.com>
The helper comment said a PID of 0 is "not worth writing", but the code treats it as an error, not a silent skip. Reword it to match. Also drop the idempotency comment in the new e2e test, which just repeated the one in the backend. Signed-off-by: Marek Nogacki <no.marek@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
podman createandpodman runalready have--pidfile, but the path is fixed at create time and reused on every start. Toolbx wants a fresh path per start so it can read the PID of the container's main process and wait on it before runningpodman exec. This adds the same--pidfileflag topodman start.After the container starts, its PID is read with libpod's
Container.PID()and written to the given path. As oncreate/run, the flag only works for a single container, is rejected with--attach, and is hidden on the remote client.Tests: new e2e specs check that the PID written to the file matches
.State.Pid, both for a freshly started and for an already-running container, plus error cases for starting more than one container (by argument and by--filter) and for--attach.Checklist
git commit -s).Fixes: #00000in commit message (if applicable)make validatepr(format/lint checks)Noneif no user-facing changes)Does this PR introduce a user-facing change?