opensource/podman
1
0
Fork 0
mirror of https://github.com/containers/podman.git synced 2025-10-24 15:03:45 +08:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #23485 from cgwalters/doc-quadlet-exec-more

Browse Source 
[ci:docs] docs/podman-systemd: Try to clarify `Exec=` more
This commit is contained in:
openshift-merge-bot[bot]
2024-08-12 13:28:34 +00:00
committed by GitHub
parent 6ef3a2347a d26341332c
commit 594f01315b
1 changed files with 13 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
docs/source/markdown/podman-systemd.unit.5.md
View File

@ -435,9 +435,19 @@ Use the host environment inside of the container.
### `Exec=`
If this is set then it defines what command line to run in the container. If it is not set the
default entry point of the container image is used. The format is the same as for
[systemd command lines](https://www.freedesktop.org/software/systemd/man/systemd.service.html#Command%20lines).
Additional arguments for the container; this has exactly the same effect as passing
more arguments after a `podman run <image> <arguments>` invocation.
The format is the same as for [systemd command lines](https://www.freedesktop.org/software/systemd/man/systemd.service.html#Command%20lines),
However, unlike the usage scenario for similarly-named systemd `ExecStart=` verb
which operates on the ambient root filesystem, it is very common for container
images to have their own `ENTRYPOINT` or `CMD` metadata which this
which this interacts with.
The default expectation for many images is that the image will include an `ENTRYPOINT`
with a default binary, and this field will add arguments to that entrypoint.
Another way to describe this is that it works the same way as the [args field in a Kubernetes pod](https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/#running-a-command-in-a-shell).
### `ExposeHostPort=`