Podman Container Visibility and State Inspection

The ability to list and monitor containers is the fundamental starting point for any container orchestration or management workflow. In a production or development environment, having a real-time, accurate overview of active workloads is critical for ensuring system stability and operational transparency. Podman, as a daemonless container engine designed for developing, managing, and running Open Container Initiative (OCI) containers on Linux, provides a robust suite of tools for this purpose. Unlike traditional container engines that rely on a centralized daemon, Podman interacts directly with the kernel and container storage, meaning the way it lists and tracks containers is deeply integrated with the underlying Linux namespace and cgroup architecture.

When an administrator or developer executes a command to list containers, they are not merely requesting a list of names; they are accessing a snapshot of the current state of the system's containerized resources. This includes visibility into which images are being utilized, the exact commands being executed within the container's entry point, the temporal data regarding when the container was instantiated, and the networking configuration regarding port mappings. For users transitioning from Docker, this experience is designed to be intuitive, as Podman maintains high command-line compatibility, allowing for a seamless migration of existing scripts and mental models while introducing advanced features such as pod-level visibility and external storage inspection.

The Core Mechanics of Podman Container Listing

The primary mechanism for observing containers in Podman is the podman ps command. This command serves as the central hub for status reporting, allowing users to verify that their services are running as expected or to identify containers that have entered a failed or exited state.

The podman ps command is highly flexible and offers several aliases to accommodate different user preferences and legacy habits. Depending on the specific operational context, a user may employ any of the following equivalent commands:

• podman ps
• podman container ps
• podman container list
• podman container ls

By default, executing podman ps without any modifiers will only display containers that are currently in a running state. This is a critical distinction for system administrators who need to differentiate between active services and dormant containers that may be consuming disk space but not CPU or memory resources.

Detailed Analysis of Default Output Columns

When a user executes the basic podman ps command, Podman returns a formatted table. Each column in this table provides a specific layer of metadata that is essential for troubleshooting and resource management.

The impact of this data is significant. For example, if a developer sees a container with a status of Up but cannot access the application via a web browser, they can immediately look at the PORTS column to verify if the host port 8080 is correctly mapped to the container port 80. If the COMMAND column shows an unexpected entry point, the developer knows that the container was instantiated with incorrect parameters, necessitating a removal and recreation.

Expanding Visibility with Advanced Flags

While the default output is useful for a quick glance, complex environments require more granular visibility. Podman provides several flags to expand the scope of the podman ps output to include stopped, external, or hidden containers.

Comprehensive State Listing with --all

The --all flag, which can be shortened to -a, is used to bypass the default filter that only shows running containers. This is an essential tool for cleaning up the system.

bash podman ps -a

In a real-world scenario, a container might crash due to an application error or a memory leak. If a user runs podman ps, the container will simply disappear from the list, potentially leading the user to believe the container was never created. By using podman ps -a, the user can see the container with a status of Exited, allowing them to then use the podman logs command to investigate the cause of the failure.

Interacting with External Storage via --external

One of the more advanced features of Podman is its ability to share container storage with other tools in the ecosystem, such as Buildah (used for building OCI images) and CRI-O (the Kubernetes Container Runtime Interface). Because of this shared storage architecture, there may be containers present on the disk that were not created by the podman run command.

To view these containers, Podman provides the --external flag:

bash podman ps --external

External containers are visually distinguished in the output. In the COMMAND and STATUS columns, these containers will be denoted with either buildah or storage. This is critical for developers using Buildah to create custom images in a layered fashion; it allows them to see the intermediate containers used during the build process that Podman would otherwise ignore.

Advanced Filtering and Output Customization

For environments running dozens or hundreds of containers, a raw table is often overwhelming. Podman provides a suite of options to filter, format, and sort the output to make it actionable.

Precision Filtering with --filter

The --filter or -f flag allows users to narrow down the list of containers based on specific conditions. Multiple filters can be applied to a single command to create highly specific queries.

bash podman ps --filter "status=running"

The impact of filtering is most evident when automating tasks via shell scripts. For instance, a cleanup script might use a filter to find all containers with a status of exited and pipe those IDs into a removal command.

Custom Formatting and JSON Output

For users who need to integrate Podman data into other tools or prefer a specific visual layout, the --format flag is indispensable. This allows the use of Go templates or the output of data in JSON format.

An example of a custom format to see only the ID, Image, Labels, and Mounts is:

bash podman ps -a --format "{{.ID}} {{.Image}} {{.Labels}} {{.Mounts}}"

This is particularly useful for DevOps engineers who are auditing container mounts or verifying that specific metadata labels have been applied to a set of containers for billing or organization purposes.

Sorting and Sizing

To better understand resource allocation and organization, Podman allows sorting and size calculations:

• The --sort flag can order the output by command, created, id, image, names, runningfor, size, or status.
• The --size or -s flag displays the total file size of the container, which includes the writable layer.

Example of sorting by name while displaying size:

bash podman ps --size --sort names

This allows a user to quickly identify "bloated" containers that are writing excessive data to their local writable layer instead of using a persistent volume.

Specialized Listing Commands and Pod Integration

Podman introduces a hierarchical structure that differs from Docker: the Pod. A pod is a group of one or more containers that share the same network namespace and other resources. This allows containers within the same pod to communicate via localhost.

Managing Pod Visibility

To list the pods currently active on the system, Podman provides a dedicated command:

bash podman pod ps

Or alternatively:

bash podman pod ls

The output of the pod listing command provides a higher-level view than the standard container list, displaying:
- Pod ID
- Pod Name
- Status
- Time of Creation
- Infra ID
- The number of containers contained within the pod

The "infra container" is a critical component mentioned in the technical specifications. An empty pod created via podman pod create consists of a single infra container. The purpose of this container is to hold the namespaces open and keep the pod alive, ensuring that any subsequent containers added to the pod via the --pod flag in the podman run command have a stable environment to join.

Container-Pod Association

When listing containers, a user may want to know which pod a specific container belongs to. This is achieved using the -p or --pod flag:

bash podman ps -p

This command adds the ID and name of the associated pod to the container list. This is vital for troubleshooting networking issues between containers that are intended to be co-located in the same pod.

Comprehensive Operational Reference Table

The following table synthesizes the various listing and inspection commands available in Podman for a complete operational overview.

Practical Application: State Transition Workflow

To understand the practical application of listing containers, consider a workflow involving a web server container (e.g., httpd).

1. Initial State: The user runs podman ps and sees the httpd container is Up.
2. Pausing the Container: The user executes podman pause httpd. This freezes the container's processes.
3. Observation: When running podman ps again, the httpd container disappears from the list because it is no longer in the "running" state.
4. Discovery: The user runs podman ps --all (or podman ps -a). The container reappears, but the STATUS column now explicitly states paused.
5. Resumption: The user executes podman unpause httpd.
6. Verification: A final run of podman ps confirms the container has returned to the Up status.

This workflow demonstrates that the podman ps command is not just a static list, but a dynamic reflection of the container's lifecycle state.

Analysis of System Integration and Storage

The behavior of podman ps is intrinsically linked to how Podman manages storage. Because Podman is daemonless, it does not have a central process that maintains a list of containers in memory. Instead, it queries the container storage—typically located in /var/lib/containers for root users or ~/.local/share/containers for rootless users.

This architectural choice has several implications for the user:
- Performance: Listing containers is extremely fast because it involves reading local state files rather than querying a remote API.
- Reliability: There is no risk of the "daemon hanging," which can happen in other container engines. If the podman ps command runs, it is seeing exactly what is on the disk.
- Interoperability: As highlighted by the --external flag, the fact that Podman uses a standardized storage layout allows it to coexist with CRI-O and Buildah. This means a container created by a Kubernetes pod (via CRI-O) can be listed and inspected by Podman on the same node, providing a powerful debugging tool for Kubernetes cluster administrators.

Conclusion

The podman ps command and its associated ecosystem of flags constitute the primary diagnostic interface for Podman. By moving beyond the basic listing of running containers and utilizing flags like --all, --external, and --format, users can achieve total visibility into their containerized environment. The integration of pod-level listing via podman pod ps further extends this visibility, allowing for the management of complex, multi-container applications that share network and resource namespaces.

For the technical professional, mastering these listing commands is not merely about seeing a table of data; it is about understanding the underlying state of the OCI containers and their relationship to the Linux host. Whether it is identifying a paused container, auditing the size of a writable layer, or tracking down a container created by an external tool like Buildah, the flexibility of Podman's listing capabilities ensures that no container remains hidden and no state transition goes unnoticed. This level of transparency is what makes Podman a preferred choice for secure, daemonless container management in modern DevOps pipelines.

Sources

1. OneUptime - List Running Containers Podman
2. Arch Linux Man Pages - podman-container-list
3. Podman Documentation - podman-ps
4. HackingNote - Podman Cheatsheets
5. Red Hat Blog - Container Information Podman
6. PhoenixNAP - Podman Tutorial