Ubuntu Manpage: podman-generate-systemd - Generate systemd unit file(s) for a container or pod

Provided by: podman_4.3.1+ds1-8ubuntu1_amd64

NAME

       podman-generate-systemd - Generate systemd unit file(s) for a container or pod

SYNOPSIS

       podman generate systemd [options] container|pod

DESCRIPTION

podman generate systemd will create a systemd unit file that can be used to control a
container or pod. By default, the command will print the content of the unit files to
stdout.

Generating unit files for a pod requires the pod to be created with an infra container
(see --infra=true). An infra container runs across the entire lifespan of a pod and is
hence required for systemd to manage the life cycle of the pod's main unit.

_Note: If you use this command with the remote client, including Mac and Windows
(excluding WSL2) machines, you would still have to place the generated units on the remote
system. Moreover, please make sure that the XDG_RUNTIMEDIR environment variable is set.
If unset, you may set it via export XDG_RUNTIME_DIR=/run/user/$(id -u).

_Note: The generated podman run command contains an --sdnotify option with the value taken
from the container. If the container does not have any explicitly set value or the value
is set to ignore, the value conmon is used. The reason for overriding the default value
container is that almost no container workloads send notify messages. Systemd would wait
for a ready message that never comes, if the value container is used for a container that
does not send notify messages. The use of the default value might have been unintentional
by the user, therefore the overridden default value._

Kubernetes Integration
A Kubernetes YAML can be executed in systemd via the podman-kube@.service systemd
template. The template's argument is the path to the YAML file. Given a workload.yaml
file in the home directory, it can be executed as follows:

$ escaped=$(systemd-escape ~/workload.yaml)
$ systemctl --user start podman-kube@$escaped.service
$ systemctl --user is-active podman-kube@$escaped.service
active

OPTIONS

--after=dependency_name
Add the systemd unit after (After=) option, that ordering dependencies between the list of
dependencies and this service. This option may be specified more than once.

User-defined dependencies will be appended to the generated unit file, but any existing
options such as needed or defined by default (e.g. online.target) will not be removed or
overridden.

--container-prefix=prefix
Set the systemd unit name prefix for containers. The default is container.

--env, -e=env
Set environment variables to the systemd unit files.

If an environment variable is specified without a value, Podman will check the host
environment for a value and set the variable only if it is set on the host. As a special
case, if an environment variable ending in * is specified without a value, Podman will
search the host environment for variables starting with the prefix and will add those
variables to the systemd unit files.

--files, -f
Generate files instead of printing to stdout. The generated files are named
{container,pod}-{ID,name}.service and will be placed in the current working directory.

Note: On a system with SELinux enabled, the generated files will inherit contexts from the
current working directory. Depending on the SELinux setup, changes to the generated files
using restorecon, chcon, or semanage may be required to allow systemd to access these
files. Alternatively, use the -Z option when running mv or cp.

--format=format
Print the created units in specified format (json). If --files is specified the paths to
the created files will be printed instead of the unit content.

--name, -n
Use the name of the container for the start, stop, and description in the unit file

--new
Using this flag will yield unit files that do not expect containers and pods to exist.
Instead, new containers and pods are created based on their configuration files. The unit
files are created best effort and may need to be further edited; please review the
generated files carefully before using them in production.

Note that --new only works on containers and pods created directly via Podman (i.e.,
podman [container] {create,run} or podman pod create). It does not work on containers or
pods created via the REST API or via podman kube play.

--no-header
Do not generate the header including meta data such as the Podman version and the
timestamp.

--pod-prefix=prefix
Set the systemd unit name prefix for pods. The default is pod.

--requires=dependency_name
Set the systemd unit requires (Requires=) option. Similar to wants, but declares a
stronger requirement dependency.

--restart-policy=policy
Set the systemd restart policy. The restart-policy must be one of: "no", "on-success",
"on-failure", "on-abnormal", "on-watchdog", "on-abort", or "always". The default policy
is on-failure unless the container was created with a custom restart policy.

Note that generating a unit without --new on a container with a custom restart policy can
lead to issues on shutdown; systemd will attempt to stop the unit while Podman tries to
restart it. It is recommended to to create the container without --restart and use the
--restart-policy option instead when generating the unit file.

--restart-sec=time
Set the systemd service restartsec value. Configures the time to sleep before restarting a
service (as configured with restart-policy). Takes a value in seconds.

--separator=separator
Set the systemd unit name separator between the name/id of a container/pod and the prefix.
The default is -.

--start-timeout=value
Override the default start timeout for the container with the given value in seconds.

--stop-timeout=value
Override the default stop timeout for the container with the given value in seconds.

--template
Add template specifiers to run multiple services from the systemd unit file.

Note that if --new was not set to true, it is set to true by default. However, if --new is
set to false explicitly the command will fail.

--wants=dependency_name
Add the systemd unit wants (Wants=) option, that this service is (weak) dependent on. This
option may be specified more than once. This option does not influence the order in which
services are started or stopped.