{
	"id": "cac19543-e66f-45a2-82c1-8a432dfe4a56",
	"created_at": "2026-04-06T02:10:59.068319Z",
	"updated_at": "2026-04-10T03:21:56.451996Z",
	"deleted_at": null,
	"sha1_hash": "611fa36d118ffe99cc14eb696758c19829b50e39",
	"title": "How to run pods as systemd services with Podman",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 158602,
	"plain_text": "How to run pods as systemd services with Podman\r\nBy Valentin Rothberg\r\nPublished: 2022-03-11 · Archived: 2026-04-06 01:34:51 UTC\r\nPodman is well known for its seamless integration into modern Linux systems, and supporting systemd is a\r\ncornerstone in these efforts. Linux commonly uses the systemd init system to manage local services such as web\r\nservers, container engines, network daemons, and all of their interdependencies. Extending these more traditional\r\nLinux system administration practices with the modern world of containers is a natural evolution.\r\nThere are two common use cases for combining systemd and containers:\r\nRunning systemd inside a container\r\nUsing systemd to run containerized applications\r\nThe first scenario is running systemd inside of a container. As Dan Walsh explains, running systemd inside a\r\ncontainer is as simple as it can be when using Podman. Podman automatically sets up several mounts in the\r\ncontainer, and systemd is good to go. While it's a comparatively small Podman feature, it was a huge leap for\r\nrunning containerized workloads when it was introduced.\r\nHistorically, other container tools have not supported systemd. Users faced the challenge of writing custom init\r\nscripts, which are prone to errors and a support burden for software vendors. With Podman, all these issues go\r\naway. Users can use systemd to install and run their applications in containers, just like anywhere else, and\r\nsoftware vendors will not face the challenges of dealing with custom init scripts written by their users.\r\nThe second scenario is using systemd to run and manage containerized applications. That means systemd starts a\r\ncontainerized application and manages its entire lifecycle. Podman simplifies this with the podman generate\r\nsystemd command, which generates a systemd unit file for a specified container or pod. Podman v1.7 and later\r\nsupport generating such units. Over time, our team has improved this feature and generated systemd unit files that\r\ncan run on other machines, similar to using a Kubernetes YAML or a Compose file. Furthermore, the tight\r\nintegration with systemd laid the foundation for auto-updates and simple rollbacks, supported since Podman v3.4.\r\nWhile there are many earlier blogs and articles on generating systemd units for containers, there are none for\r\ngenerating these units for pods. But before going into these details, I want to review what a pod is.\r\n[ Getting started with containers? Check out this free course. Deploying containerized applications: A technical\r\noverview. ]\r\nWhat is a pod?\r\nThere are several different parts in a pod, and I think Brent Baude explains it best with the great figure below:\r\nhttps://www.redhat.com/sysadmin/podman-run-pods-systemd-services\r\nPage 1 of 6\n\nThe first thing to notice is that a pod consists of one or more containers. The group shares control groups\r\n(cgroups) and specific namespaces such as the PID, network, and IPC namespace. The shared cgroups ensure that\r\nall containers have the same resource constraints. The shared namespaces allow the containers to communicate\r\nwith each other more easily (such as through localhost or interprocess communication).\r\nYou can also see a special infra container. Its primary purpose is to hold specific resources associated with the pod\r\nopen, such as ports, namespaces, or cgroups. The infra container is the pod's top-level container, and it's created\r\nbefore other containers and destroyed last. You use the infra container when generating systemd units for a pod, so\r\nkeep in mind that this container runs for the pod's entire lifespan. It also implies that you cannot generate systemd\r\nunits for pods without an infra container (such as --infra=false ).\r\nLast but not least, you see multiple conmon processes running, one per container. \"Common\" is short for\r\ncontainer monitor, which sums up its main functionality. It also takes care of forwarding logs and performing\r\ncleanup actions once the container has exited. The conmon process starts before the container and instructs the\r\nunderlying container runtime (such as runc or crun ) to create and start the container. It also exits with the\r\ncontainer's exit code allowing for using it as a systemd service's main process.\r\nGenerating systemd units for a pod\r\nPodman generates exactly one system unit for a container. Once installed, use systemctl to start, stop, and\r\ninspect the service. The main PID of each unit is the container's conmon process. This way, systemd can read the\r\ncontainer's exit code and act according to the configured restart policy. For more details on the units, please refer\r\nto Running containers with Podman and systemd shareable services and Improved systemd Podman with Podman\r\n2.0.\r\nhttps://www.redhat.com/sysadmin/podman-run-pods-systemd-services\r\nPage 2 of 6\n\nGenerating units for a pod is very similar to starting a container. Each container in the pod has a dedicated\r\nsystemd unit, and each unit depends on the pod's main systemd unit. This way, you can continue using\r\nsystemctl to start, stop, and inspect the pod's main service; systemd will take care of (re)starting and stopping\r\nthe containers' services along with the main service.\r\nThis example creates a pod with two containers, generates unit files for the pod, and then installs the files for the\r\ncurrent user:\r\n$ podman pod create --name=my-pod\r\n635bcc5bb5aa0a45af4c2f5a508ebd6a02b93e69324197a06d02a12873b6d1f7\r\n$ podman create --pod=my-pod --name=container-a -t centos top\r\nc04be9c4ac1c93473499571f3c2ad74deb3e0c14f4f00e89c7be3643368daf0e\r\n$ podman create --pod=my-pod --name=container-b -t centos top\r\nb42314b2deff99f5877e76058ac315b97cfb8dc40ed02f9b1b87f21a0cf2fbff\r\n$ cd $HOME/.config/systemd/user\r\n$ podman generate systemd --new --files --name my-pod\r\n/home/vrothberg/.config/systemd/user/pod-my-pod.service\r\n/home/vrothberg/.config/systemd/user/container-container-b.service\r\n/home/vrothberg/.config/systemd/user/container-container-a.service\r\nAs expected, Podman generated three .service files, one for each container plus the top-level one for the pod.\r\nPlease refer to the appendix at the end of the article to see the entire contents of the unit files. The units generated\r\nfor the two containers look like standard container units plus the following systemd dependencies:\r\nBindsTo=pod-my-pod.service : The container unit is \"bound\" to the unit of the pod. If the pod's unit is\r\nstopped, this unit will be stopped, too.\r\nAfter=pod-my-pod.service : The container unit starts after the unit of the pod.\r\nThe pod's main service's dependencies further make sure that if a container unit does not start successfully, the\r\nmain pod's main unit will also fail.\r\nThat is all you need to know about generating systemd units for pods with Podman. Once you've reloaded systemd\r\nvia systemctl --user daemon-reload , start and stop the pod.service at will. Have a look:\r\n# Reload the daemon\r\n$ systemctl --user daemon-reload\r\n# Start the pod service and make sure the service is running\r\n$ systemctl --user start pod-my-pod.service\r\n$ systemctl --user is-active pod-my-pod.service\r\nactive\r\nhttps://www.redhat.com/sysadmin/podman-run-pods-systemd-services\r\nPage 3 of 6\n\n# Make sure the pod and its containers are running\r\n$ podman pod ps\r\nPOD ID NAME STATUS CREATED INFRA ID # OF CONTAINERS\r\n6dd1090d4ca6 my-pod Running 2 minutes ago 85f760a5cfe5 3\r\nuser $ podman container ps\r\nCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES\r\n85f760a5cfe5 localhost/podman-pause:4.0.2-1646319369 5 minutes ago Up 5 minutes ago\r\n44a7e60b9563 quay.io/centos/centos:latest top 5 minutes ago Up 5 minutes ago conta\r\n31f24bdff747 quay.io/centos/centos:latest top 5 minutes ago Up 5 minutes ago conta\r\nGreat, everything is working as expected. You can use systemctl to start the services, and Podman lists the pods\r\nand their containers correctly. For the sake of consistency, have a final look at how to stop the pod service.\r\n# Stop the pod service\r\n$ systemctl --user stop pod-my-pod.service\r\n# Make sure the pod and its containers are removed\r\n$ podman pod ps -q\r\n$ podman container ps -q\r\n# Make sure the services are inactive\r\n$ systemctl --user is-active pod-my-pod.service container-container-a.service container-container-b.service\r\ninactive\r\ninactive\r\ninactive\r\nThe take-home message is that Podman generates systemd units for pods just as it does for containers. The\r\ndependencies among these units are set in a way that you just need to interact with the pod's main unit, and\r\nsystemd takes care of starting and stopping the containers' units.\r\nAppendix\r\nPodman generates the following unit files for a pod and the two related containers.\r\npod-my-pod.service\r\nDescription=Podman pod-my-pod.service\r\nDocumentation=man:podman-generate-systemd(1)\r\nWants=network-online.target\r\nAfter=network-online.target\r\nRequiresMountsFor=\r\nRequires=container-container-a.service container-container-b.service\r\nBefore=container-container-a.service container-container-b.service\r\nhttps://www.redhat.com/sysadmin/podman-run-pods-systemd-services\r\nPage 4 of 6\n\n[Service]\r\nEnvironment=PODMAN_SYSTEMD_UNIT=%n\r\nRestart=on-failure\r\nTimeoutStopSec=70\r\nExecStartPre=/bin/rm -f %t/pod-my-pod.pid %t/pod-my-pod.pod-id\r\nExecStartPre=/usr/bin/podman pod create --infra-conmon-pidfile %t/pod-my-pod.pid --pod-id-file %t/pod-my-pod.pod\r\nExecStart=/usr/bin/podman pod start --pod-id-file %t/pod-my-pod.pod-id\r\nExecStop=/usr/bin/podman pod stop --ignore --pod-id-file %t/pod-my-pod.pod-id -t 10\r\nExecStopPost=/usr/bin/podman pod rm --ignore -f --pod-id-file %t/pod-my-pod.pod-id\r\nPIDFile=%t/pod-my-pod.pid\r\nType=forking\r\n[Install]\r\nWantedBy=default.target\r\ncontainer-container-a.service\r\n[Unit]\r\nDescription=Podman container-container-a.service\r\nDocumentation=man:podman-generate-systemd(1)\r\nWants=network-online.target\r\nAfter=network-online.target\r\nRequiresMountsFor=%t/containers\r\nBindsTo=pod-my-pod.service\r\nAfter=pod-my-pod.service\r\n[Service]\r\nEnvironment=PODMAN_SYSTEMD_UNIT=%n\r\nRestart=on-failure\r\nTimeoutStopSec=70\r\nExecStartPre=/bin/rm -f %t/%n.ctr-id\r\nExecStart=/usr/bin/podman run --cidfile=%t/%n.ctr-id --cgroups=no-conmon --rm --pod-id-file %t/pod-my-pod.pod-id\r\nExecStop=/usr/bin/podman stop --ignore --cidfile=%t/%n.ctr-id\r\nExecStopPost=/usr/bin/podman rm -f --ignore --cidfile=%t/%n.ctr-id\r\nType=notify\r\nNotifyAccess=all\r\n[Install]\r\nWantedBy=default.target\r\ncontainer-container-b.service\r\n[Unit]\r\nDescription=Podman container-container-b.service\r\nDocumentation=man:podman-generate-systemd(1)\r\nWants=network-online.target\r\nhttps://www.redhat.com/sysadmin/podman-run-pods-systemd-services\r\nPage 5 of 6\n\nAfter=network-online.target\r\nRequiresMountsFor=%t/containers\r\nBindsTo=pod-my-pod.service\r\nAfter=pod-my-pod.service\r\n[Service]\r\nEnvironment=PODMAN_SYSTEMD_UNIT=%n\r\nRestart=on-failure\r\nTimeoutStopSec=70\r\nExecStartPre=/bin/rm -f %t/%n.ctr-id\r\nExecStart=/usr/bin/podman run --cidfile=%t/%n.ctr-id --cgroups=no-conmon --rm --pod-id-file %t/pod-my-pod.pod-id\r\nExecStop=/usr/bin/podman stop --ignore --cidfile=%t/%n.ctr-id\r\nExecStopPost=/usr/bin/podman rm -f --ignore --cidfile=%t/%n.ctr-id\r\nType=notify\r\nNotifyAccess=all\r\n[Install]\r\nWantedBy=default.target\r\nSource: https://www.redhat.com/sysadmin/podman-run-pods-systemd-services\r\nhttps://www.redhat.com/sysadmin/podman-run-pods-systemd-services\r\nPage 6 of 6",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://www.redhat.com/sysadmin/podman-run-pods-systemd-services"
	],
	"report_names": [
		"podman-run-pods-systemd-services"
	],
	"threat_actors": [],
	"ts_created_at": 1775441459,
	"ts_updated_at": 1775791316,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/611fa36d118ffe99cc14eb696758c19829b50e39.pdf",
		"text": "https://archive.orkl.eu/611fa36d118ffe99cc14eb696758c19829b50e39.txt",
		"img": "https://archive.orkl.eu/611fa36d118ffe99cc14eb696758c19829b50e39.jpg"
	}
}