opensource/podman
1
0
Fork 0
mirror of https://github.com/containers/podman.git synced 2025-10-25 02:04:43 +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=` ### `Exec=`
If this is set then it defines what command line to run in the container. If it is not set the Additional arguments for the container; this has exactly the same effect as passing
default entry point of the container image is used. The format is the same as for more arguments after a `podman run <image> <arguments>` invocation.
[systemd command lines](https://www.freedesktop.org/software/systemd/man/systemd.service.html#Command%20lines).
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=` ### `ExposeHostPort=`