6 Working With Podman Services

Podman can integrate with Systemd services to manage pods and containers as system services. By using Podman service wrappers, you can configure containers or pods to start at system boot and you can manage them similarly as other services that run on the host system.

Podman provides the tools to automatically generate Systemd service wrapper configuration files for any containers or pods on the system, so that you can manage container infrastructure using Systemd.

You can use Systemd user services if you're running containers as a standard user, or you can configure system level services if you're running containers as the root user.

Setting SELinux Permissions for Container and Pod Service Wrappers

If you have set SELinux to enforcing mode on the system, you must turn on the container_manage_cgroup permission so that Systemd can be used to start, stop, and monitor containers:

sudo setsebool -P container_manage_cgroup on

About Quadlets

Instead of generating a Podman service wrapper by using the podman generate systemd command and then maintaining all the Systemd unit files individually, you can maintain a single Quadlet and rely on the podman-systemd daemon to regenerate those Systemd unit files for you whenever they're needed.

The other practical benefit of using a Quadlet is that whenever a new version of Podman is released, you can roll out fixes and enhancements to any templated Systemd unit files by reinitializing the affected services.

Note:

On Oracle Linux 8 hosts, Quadlets can only be run with root permissions. For more information, see Quadlets Fail on Oracle Linux 8 For An Unprivileged User.

Creating Quadlet Containers

Quadlet containers are managed by using a unit file with the .container file extension. It must also contain a [Container] section, for example:

[Unit]
Description=your-description
After=local-fs.target

[Container]
Image=container-registry.oracle.com/os/oraclelinux:8-slim
Exec=your-command-here

[Install]
# Start by default on boot
WantedBy=multi-user.target default.target

To create a Quadlet container that runs with root permissions, store that .container file in either of the /usr/share/containers/systemd/ or /etc/containers/systemd/ directories, and then reload Systemd services:

sudo systemctl daemon-reload

To create a Quadlet container that runs with standard user permissions, administrators can create quadlet files in the /etc/containers/systemd/users/${USER_ID} directory for each individual user, or individual users can store .container files in their' $HOME/.config/containers/systemd/ directory, and then reload Systemd services:

systemctl --user daemon-reload

To examine the unit files that have been created, you can use the -dryrun option with the quadlet command:

/usr/libexec/podman/quadlet -dryrun

Add the -user option for Quadlet containers that run without root permissions.

You can now manage the Quadlet the same way as any other Systemd service by using the systemctl command. For example, to start a quadlet container called myoracle that was confirmed during the dry run, run the following command:

sudo systemctl start myoracle

For more information, see the podman-systemd.unit(5) manual pages.

Using the Podman Login Shell

In Oracle Linux 9, you can use the Podman login shell to run shell commands in a container. This feature provides the advantage of ensuring that users are kept within established boundaries while working inside containers. Users are configured to use the /usr/bin/podmansh shell command instead of normal shells such as /bin/bash. The command starts the user's session in a rootless container called podmansh. This container continues to run until the user exits the session, at which point the container is removed.

Administrators configure users to use this feature through Quadlet files. These files define the parameters for users when they work in containers, such as the visibility of the host system when users are in the containers, access limitations, security privileges, and resource usage. For more information, see About Quadlets.

The following is an example of how you can configure a user to use the Podman login shell and other set parameters when working in a container. Assume that the quadlet applies to a specific ${USER_ID}, and the quadlet is podmansh.container.

[Unit]
Description=The Podmansh container
After=local-fs.target

[Container]
Image=container-registry.oracle.com/os/oraclelinux:8-slim
ContainerName=podmansh
RemapUsers=keep-id
RunInit=yes

Exec=sleep infinity

[Install]
RequiredBy=default.target

You can define more parameters in the [Container] section to further specify what a user can do when inside a container. See the podman-systemd.unit(5) manual page for details.

Note that the name of the container (ContainerName) must be podman. In this manner, the /usr/bin/podmansh shell command runs podman exec in the podmansh container.

The user with the ID that matches the quadlet's ${USER_ID} would log in as follows:

ssh user@systemname

All the settings defined for the user in the quadlet file transparently run without any need for user or administrator intervention.

The Podman login shell and other defined parameters combine to isolate the user and therefore ensures container security. The container is removed at the end of a session, and logging back in re-creates the same confined environment for the user. So, working with containers becomes more straightforward.

Generating Podman Service Wrappers

Instead of writing a Systemd service wrapper from scratch, use the podman generate systemd command to automatically generate the service configuration file.

If you intend to run containers as root user system services, store the container service wrapper configuration files in /etc/systemd/system/. If you intend to run containers as a standard user, save the container service wrapper configuration files in $HOME/.config/systemd/user/.

Generating Podman Service Wrappers for Containers

To generate a Systemd service wrapper for an individual container and store it in the $HOME/.config/systemd/user directory:

podman generate systemd --name containername > $HOME/.config/systemd/user/container-containername.service

Generating Podman Service Wrappers for Pods

To generate a Podman service wrapper for a specific pod, use the following command:

podman generate systemd --name podname

However, to include generating service wrapper configuration files for all the containers within a pod itself, use the --file option with the command. In this case, run the command in the directory where you intend to generate the files.

Suppose that in $HOME/.config/systemd/user, you want to generate Podman service wrappers for both mypod and its containers. You would run the following commands:

cd $HOME/.config/systemd/user/
podman generate systemd --files --name mypod

With this command, the service wrapper that's responsible for mypod includes dependencies on each of the container wrappers that are required for the pod to run successfully.

If you start or stop the pod by using its Systemd service wrapper, the container services automatically trigger the same action.

Managing Podman Services

Systemd services are all managed by using the systemctl command.

After you have configured Systemd service wrappers for any containers or pods, you can use systemctl commands to manage those containers or pods as services.

If you're running containers as a standard user, all systemctl commands must use the --user option.

Starting and Restarting Podman Services

Caution:

If a container or pod is already running outside of the Systemd service wrapper, the service wrapper is unable to start the container or pod. If so, use the podman stop or podman pod stop command to stop the container or pod first.

As a root user, you can start a container if its service configuration is stored in /etc/systemd/system/, for example:

sudo systemctl start container-containername.service

As a standard user, if you stored a service configuration in $HOME/.config/systemd/user, you can start the container in the same way but you must use the --user option:

systemctl --user start container-containername.service

Starting the service wrapper for a pod uses a parallel command syntax, as follows:

sudo systemctl start pod-podname.service

You can restart the service wrapper for a container or pod by using the systemctl restart command. The following command restarts a pod as a standard user:

systemctl --user restart pod-podname.service

If you start or restart a pod, all containers that are part of the pod are equally started or restarted.

Stopping Podman Services

You can stop a container or pod by using the systemctl stop command. The following command stops a pod as a standard user:

systemctl --user stop pod-podname.service

If you start or restart a pod, all containers that are part of the pod are equally started or restarted.

Checking the Status of Podman Services

You can check the current status of any service wrapper you create for containers or pods with the systemctl status command, for example:

systemctl --user status container-containername.service

Enabling Automated Restore for Podman Services

You can add custom configuration steps when you generate service wrappers for Podman containers.

For example, to create a service wrapper that always restarts after a one second timeout, set the --restart-policy flag with a parameter value, as shown:

sudo systemctl generate systemd --restart-policy=always -t 1 containername > /etc/systemd/user/container-containername.service

To set the service wrapper to run automatically when the system starts up, type:

sudo systemctl enable container-containername.service

You can use the same commands with the service wrapper for a pod:

sudo systemctl enable pod-podname.service

If services are running as a standard user, you would need to give the user permission to run processes when they're not logged in. Otherwise, the user can't enable the service. Type the following command as the root user:

sudo loginctl enable-linger user

For more information, see https://docs.oracle.com/en/learn/use_systemd/index.html .

Changing Podman Service Wrapper Configuration

The Systemd service wrapper configuration files that are generated by Podman follow standard Systemd configuration format and specification. You can change any of the service wrapper configuration files that are generated by manually editing these files within a text editor.

Change the behavior of Systemd services wrappers on Oracle Linux 8 by following the instructions at Oracle Linux 8: Managing the System With systemd. On Oracle Linux 9, see Oracle Linux 9: Managing the System With systemd for more information.

For more information about how you can make modifications to the service wrapper you have generated with the podman generate systemd command, see https://docs.podman.io/en/latest/markdown/podman-generate-systemd.1.html.