Fedora is testing conmon v3, a Rust replacement for the C container monitor used with Podman. The change concerns a small process with an important job: keeping container input, output, logs and exit status accessible after the Podman command that launched the container has finished.
The Podman and Fedora Quality teams organized their community test week for October 12–18, 2026. That scheduled event has now ended, but the work remains relevant to developers and administrators assessing the replacement. The Fedora test announcement identifies two reasons for the rewrite: preventing common memory errors in safe Rust code and giving logging backends a shared interface that is easier to extend and test.
This is a compatibility testing effort, not, by itself, evidence that every Fedora installation has switched monitors. For users, the immediate question is straightforward: can the Rust implementation handle existing container workflows without changing their behavior?
What conmon does in the Podman stack
Conmon is neither Podman itself nor the runtime that starts a container. It sits between the container manager and an Open Container Initiative runtime, such as crun or runc, and maintains communication with an individual container.
The conmon v3 project documentation describes a monitor that detaches from its launching process, starts the runtime, maintains an attachment socket, captures container output and records the container’s exit time and status. Output can go to a log file or the systemd journal. The Rust implementation retains this basic role.
That separation matters because launching an application and supervising its output are different tasks. A developer might start a database container, close the launching terminal, then inspect its logs later. The monitor provides continuity between those actions.
A monitor can also produce misleading symptoms when something goes wrong. Missing output does not necessarily mean the application printed nothing. A stuck terminal does not necessarily mean the application has stopped responding. Testing needs to distinguish application behavior from problems in the machinery carrying its input, output and status.
Why Rust helps, and what it cannot promise
Memory safety is the main reason to pay attention to the implementation language here. Rust checks ownership and borrowing rules, helping developers avoid mistakes involving invalid memory access. These checks address a class of programming errors; they do not establish that a program behaves correctly in every situation.
The boundary deserves care. Rust supports operations that require the programmer to uphold safety guarantees manually. The Rust language documentation on unsafe code explains that these operations include dereferencing raw pointers and calling unsafe functions. An unsafe block does not mean a defect exists, but it does mean the compiler cannot verify every relevant safety condition.
For conmon, the sensible expectation is therefore narrower than “Rust makes containers secure.” The rewrite aims to reduce exposure to common memory errors while preserving the behavior users already depend on. Incorrect exit reporting, dropped output or faulty shutdown handling would still be defects, regardless of language.
Nor should the rewrite be treated as a performance result. A claim that container startup is faster, or that each monitor consumes less memory, needs comparable measurements. Changing languages is not a benchmark.
Readers following Ubuntu’s transition to Rust-based core utilities should keep the two changes separate. Conmon concerns container supervision, not replacement of general shell utilities. The shared engineering question is whether safer implementation choices preserve the behavior that existing workflows expect.
Compatibility means more than starting a container
A container that starts successfully has passed only the opening check. A useful assessment follows it through normal work, interaction and shutdown. Think of a development container used for compiling a project: it must accept input, display diagnostics, run additional commands and return a meaningful result when the build finishes.
The most useful comparisons keep the workload unchanged. Use the same image, application configuration, runtime and user account for the baseline and replacement monitor. Otherwise, a different image version or runtime setting may explain a difference that appears to implicate conmon.
| Area | Useful comparison | Potential failure |
|---|---|---|
| Output capture | Check recognizable messages from both output streams | Missing or truncated diagnostics |
| Interactive use | Enter input and finish a terminal session | Unresponsive input or a terminal that does not return |
| Command execution | Run another process inside a running container | Missing output or a command that hangs |
| Exit reporting | Use a workload with a known exit status | The host receives the wrong result |
| Shutdown | Stop the workload and inspect its final state | The container remains active unexpectedly |
Output and exit status deserve separate checks
A program can print the expected message and still return the wrong status. Conversely, it can return the expected status while losing a useful diagnostic. Treat those as separate observations rather than one general “worked” result.
For an automated build, this distinction matters. Suppose a test process deliberately returns a failure status, but the surrounding workflow sees success. The visible output might look convincing while the automation makes the wrong decision. A deliberate, known failure is therefore a better check than relying only on a successful command.
Use recognizable messages rather than a large, unfamiliar application log for the opening comparison. Once the basic behavior is established, repeat the workload that represents actual use. A small reproducible test helps isolate a defect; a realistic workload helps establish whether it matters to the user.
Interactive testing should resemble actual work
An interactive check should involve more than seeing a prompt. Enter input, run a command and leave the session normally. Where the workflow involves reconnecting to an application or changing terminal dimensions, include those actions in the comparison.
Keep a short record of what happened at each stage. “The shell accepted input but never returned control after exit” gives a maintainer a much better starting point than “terminal broken.” Precise descriptions save everyone a round of detective work.
Confirm the selected monitor before testing
Installing a package and selecting it are separate steps. Fedora’s conmon v3 setup and sanity test uses the conmon-v3 package from the updates-testing repository and selects /usr/bin/conmon-v3 through the conmon_path setting in a configuration drop-in under /etc/containers/containers.conf.d/.
The same test checks startup, output capture, execution inside a container, stopping, exit status propagation and an interactive terminal. Its deliberate exit-status check expects 42. It also notes that a forced-stop warning after its two-second timeout does not, on its own, establish a monitor failure.
Use a disposable virtual machine or test host without important data. Before changing configuration, record the current monitor selection and preserve any configuration file that already exists. A reversible experiment is preferable to an afternoon spent reconstructing yesterday’s setup.
Podman exposes the information needed to identify its selected monitor. The Podman system information documentation shows a conmon section containing the package, executable path and version, alongside host details such as the OCI runtime and security configuration.
Capture that information with the test record. The package being present on disk is not enough; the reported path should identify the intended executable. If both rootless and rootful operation matter to the assessment, record each environment separately rather than assuming one result covers both.
For clean comparisons, use newly created test containers after changing monitor selection. Keep the baseline and replacement runs clearly named, and do not mix their logs. When restoring the previous setup, check the selected monitor again before treating the next run as a baseline.
Quadlet services need their own assessment
A container launched manually is not a substitute for testing the service configuration used in practice. An administrator assessing a background application should include the service manager in the experiment, not stop after an interactive shell succeeds.
Quadlet converts declarative container files into systemd services. The Podman Quadlet documentation describes generation during boot and service-manager reloads, with support for both system and user services. It also documents startup considerations, including the time required to pull or build an image.
For a disposable service, compare normal startup, an intentional stop and a subsequent start. Check the application’s output as well as the service’s reported state. If restart behavior matters, test it deliberately rather than waiting for an accidental failure to provide an answer.
Keep unrelated variables stable. Pre-fetching the same image for both runs, for example, avoids confusing a download delay with a supervision problem. Preserve the original service definition so that any comparison tests the monitor rather than an unnoticed configuration edit.
The goal is not to make every test more elaborate. It is to match the assessment to the deployment. A developer’s interactive shell and an unattended system service exercise different parts of the workflow.
What the published results establish
The published Podman conmon v3 test results contain successful submissions for the sanity check and checks covering exit reporting, file logs, standard input, interactive use, execution and stopping, and journald logging. Submitted profiles include Fedora workstation and server installations as well as virtual machines.
These reports provide evidence that the tested combinations worked. They do not establish that every workload, runtime or machine configuration has passed. The results are community submissions, not a controlled performance study or a guarantee of production readiness.
A useful reading is therefore modest: basic compatibility has received practical testing on more than one setup. The next valuable contribution may be a different configuration or a repeatable edge case, rather than another identical successful shell session.
Successful reports still have value. A failure identifies a problem; a pass identifies a configuration that has actually been exercised. Neither should be stretched beyond the conditions recorded.
Report differences, not just impressions
When a comparison fails, preserve the evidence before changing several settings at once. Note the last action that worked, the first action that failed and whether repeating the same steps produces the same result.
For a suspected monitor defect, check the conmon v3 issue tracker for an existing report before opening another. Separate what was observed from what is suspected. “Output stops after reconnecting” is an observation; “the logging backend is broken” is a diagnosis that may still need proof.
A useful report should contain:
- The Fedora release, relevant package versions and selected monitor path.
- The user mode, runtime and steps needed to reproduce the behavior.
- The expected result and the actual result, including relevant output.
- The outcome of the same comparison with the previous monitor.
Review diagnostic material before publishing it. Remove credentials and sensitive application data, but retain the technical details needed to reproduce the issue. If removing private configuration changes the behavior, say so rather than presenting the reduced example as an exact reproduction.
Who should test conmon v3 now?
Developers with disposable development containers and administrators with representative test services have the clearest reason to participate. Their contribution is not simply confirming that Rust code runs. It is checking whether established Podman workflows retain their expected behavior.
Users whose containers support important daily work should keep experimentation separate from that environment. There is no need to turn a working host into a test bench just because the replacement uses a different language.
The standard for success is deliberately unexciting: complete logs, responsive terminals, correct exit statuses and predictable service operation. Memory safety provides a reason to pursue the rewrite. Compatibility testing determines whether the replacement can do the existing job without surprises.