Conversation
) The live watch tests failed under heavy parallelism with messages that blamed the sync or the rebuild (#1874). Instrumenting one file change end to end showed the event was neither lost nor late: **the watcher was never created**. `RecommendedWatcher::new` returned `Too many open files (os error 24)` because the user's inotify instances were exhausted (128 by default, 109 in use when measured), which happens when eight watchers start at once on a machine near its limit. **podup itself is correct:** `podup watch` prints `podup: error: watch error: Too many open files` and exits non-zero. **The tests were silent:** they spawned `engine.watch()`, never checked the task, polled the container until their deadline, and failed on the condition they were waiting for. `poll_with_watch` now owns that poll and checks on every tick whether the watch task finished; if it did, the test fails with the task's own result (`watch() returned early: <error>`). Every watch test that spawns `watch()` uses it; no container assertion changed. This does not make the tests pass without free inotify instances; it makes them say why they fail. **Proof:** a self-test with a task that fails at once requires the helper to report it; making the helper ignore a finished task fails it. The live watch group: 11/11 twice at four threads. Full suite: 2780. **Not covered by a test:** the CLI's print-and-exit when the watcher cannot be created. Reproducing it means exhausting the user's inotify instances, which every process of that user shares, so it was verified by hand during the investigation and not pinned. Closes #1874 Signed-off-by: Jaro-c <75870284+Jaro-c@users.noreply.github.com>
…#1889) Inside the `podman-machine-default` WSL distro there is no user systemd session, so Podman's default cgroup manager has nothing to talk to and every `RUN` step of a build dies. The remedy is one line in `containers.conf`. podup said nothing about it and passed the runtime's failure through as it arrived. When a build fails, podup now reads `host.cgroupManager` over the same socket the build used, and when it is `systemd` it appends one line naming `cgroup_manager = "cgroupfs"` and the file the key goes in. What it deliberately does not do: - it never runs on a successful build, so a healthy build pays nothing, - it reads the machine running Podman, not the machine running podup, which over a remote socket are not the same host, - if the info call fails for any reason, the original build error reaches the caller unchanged. `systemd` is the correct value on an ordinary Linux host too, so the line is phrased as a hint with its condition named, not as a diagnosis. Four tests pin the hint to the condition, not to the wording of a runtime message I do not control: `systemd` appends it, `cgroupfs` does not, a failing info call leaves the error alone, and a successful build issues no info request. I broke each behaviour in turn and each one turned exactly its own test red, with the other three green. The README already carries the stanza and the check command; this documents the new hint in `docs/commands.md`. The Windows framing is in #1888, so I left the README alone here to avoid saying it twice. Closes #1778 Signed-off-by: Jose <75870284+Jaro-c@users.noreply.github.com>
…gnature (#1888) A Windows host with Smart App Control enabled refuses to launch `podup-windows-$ARCH.exe`: the executable carries no Authenticode signature, and a fresh release asset has no SmartScreen reputation either. Until now podup said nothing about it, so the first a Windows user heard of the limitation was a binary that would not start. I say three things and no more than three: - the binary is unsigned, and Smart App Control refuses it, - the Ed25519 signature over `SHA256SUMS` and the SHA-256 checksum that `install.ps1` verifies do not help, because Smart App Control reads the Authenticode signature embedded in the PE instead, - the route that works today is the Linux build inside the `podman-machine-default` WSL distro, which the README already documents. I deliberately do not claim what SmartScreen on its own does, because I have not measured it on a Windows host, and I do not give a recipe for turning Smart App Control off. There is no per-binary override, and telling people to disable it is not advice I want in the README. This does not close #1774. Signing needs a certificate whose private key lives in an HSM or a cloud signing service, and I have not chosen between Azure Trusted Signing and a commercial OV/EV certificate yet. This is the half that is true whichever I pick. Refs #1774, #1778. Signed-off-by: Jose <75870284+Jaro-c@users.noreply.github.com>
…#1828) Closes #1825, split out of #1811 which I closed as not reproduced. ## The gap `internal/engine/container/userns_tests.rs` builds its containers through a helper that calls `create_and_start` directly and never creates a pod, so every assertion in it passes whatever the pod path does. A pod is a different path: `internal/engine/pod/mod.rs` sends the pod spec, `PodSpecGenerator` carries no ID-mappings field of its own, and a member container suppresses its own namespace when it joins the pod. Nothing covered it. ## What the test asserts A project with `x-podman-pod: true`, reading `/proc/self/uid_map` and `id -u` from the member: | `userns_mode` | `uid_map` | `id -u` | |---|---|---| | `auto` | `0 1 1024` | 0 | | `auto:size=2048` | `0 1 2048` | 0 | | `keep-id:uid=321,gid=654` | `0 1 321` | 321 | **Three rows rather than one, and that is the point.** A path that dropped the option and fell back to the default would answer `0 1 1024`, which is exactly what `auto` answers. A test that asserted only `auto` could not tell a working option path from a silent no-op. Only the other two rows separate them. It also asserts the container's `Pod` field equals the project's pod, so a regression that quietly created the container outside the pod cannot leave every mapping assertion passing while the pod path goes unexercised. ## The control I sabotaged the production path, not the test: made `pod_userns` keep only the base mode and discard everything after the colon, which is the silent no-op #1797 was about. userns-pod-auto-size-2048: uid_map size must be 2048 for userns_mode "auto:size=2048", got " 0 1 1024" left: 1024 right: 2048 The pod fell back to the `auto` default and the test named the case, the mode, the expected size and the one it got. That is the regression this test exists to catch, and it catches it. ## Tear-down A guard that runs on drop, so a panicked assertion cannot leave pods holding subordinate ID ranges. A host whose range is exhausted fails every later run with `not enough unused IDs in user namespace`, which reads like a podup defect and is not: that is what an exhausted range looked like on this machine this morning, and it cost an hour before the cause was found. Gates, all rc=0: the live test with `PODUP_REQUIRE_PODMAN=1` (1 passed, 31.74s, so it ran rather than skipped), `cargo test --locked --lib --all-features` (2026 passed), `cargo fmt --all --check`, `cargo clippy --locked --all-targets --all-features -- -D warnings`. --------- Signed-off-by: Jaro-c <75870284+Jaro-c@users.noreply.github.com> Signed-off-by: Jose <75870284+Jaro-c@users.noreply.github.com>
…ppens (#1890) Four small corrections to what #1888 and #1889 shipped, found while reading the diff since v5.9.7 before cutting 5.9.8. **The Smart App Control notice could not reach the user it was for.** `install.ps1` printed it after a successful install. On a host where Smart App Control refuses the binary, the first launch is the `--version` self-test in `Test-StagedVersion`, which fails and exits before that line. The pointer now rides on both "Could not run ... --version" failures, and the success path no longer prints it: a launch that worked already shows Smart App Control let it through. Whether the refusal surfaces as an exception or a non-zero exit is not measured, so both paths carry it. Parts 6 and 7 of `version-self-test.ps1` now assert the refusal names Authenticode; that fixture runs on the Windows lane, and I have no `pwsh` here, so CI is the first run of it. **The README sent a Fedora distro to the apt installer.** The Windows section said to install podup inside `podman-machine-default` with the apt line at the top or the non-apt script. That distro is Fedora-based, so only the script applies. **A blank line before the cgroup hint.** buildah's `error` field already ends in a newline and the hint was pushed after another one. The error is trimmed only on the path that appends the hint; without a hint it reaches the caller byte for byte. The systemd test now asserts `\nhint:` and not `\n\nhint:`, and reverting the trim turns it red on that assertion. **The info-call-failure test only excluded this one hint.** It now asserts no `hint:` of any kind, like its cgroupfs sibling. Test plan: - [x] `cargo test --lib cgroup_hint`: 4 passed - [x] `cargo fmt --check`, `cargo clippy --all-targets -- -D warnings`: clean - [ ] `version-self-test.ps1` on the Windows lane --------- Signed-off-by: Jaro-c <75870284+Jaro-c@users.noreply.github.com>
Jaro-c
added
prio:P3
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.
Release 5.9.8. User-facing changes since 5.9.7: a build failure under
cgroup_manager = "systemd"now names thecgroupfssetting (#1889),install.ps1points at the missing Authenticode signature when the self-test launch is refused (#1890), and the README's Windows section (#1888, #1890). #1887 and #1828 only touch tests. Version stamps bumped in #1891.