summaryrefslogtreecommitdiff
path: root/docs/source/markdown/podman-generate-systemd.1.md
Commit message (Collapse)AuthorAge
* "pod" was being truncated to "po" in the names of the generated systemd unit ↵Gavin Campbell2020-06-21
| | | | | | | | files. s/po/pod Signed-off-by: Gavin Campbell <gavin@gavincampbell.dev>
* correct the absolute path of `rm` executableYuan-Hao Chen2020-06-19
| | | | Signed-off-by: Yuan-Hao Chen <yhchen0906@gmail.com>
* generate systemd: create pod templateValentin Rothberg2020-06-11
| | | | | | | | | | Create a new template for generating a pod unit file. Eventually, this allows for treating and extending pod and container generation seprately. The `--new` flag now also works on pods. Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
* Added new flags to 'podman generate systemd' to change the unit name prefixLuap992020-05-22
| | | | | | | | | | | | | --container-prefix <string> - default 'container' Systemd unit name prefix for containers --pod-prefix <string> - default 'pod' Systemd unit name prefix for pods --separator <string> - default '-' Systemd unit name seperator between name/id and prefix Signed-off-by: Paul Holzinger <paul.holzinger@web.de>
* Update podman-generate-systemd man pageSujil022020-04-16
| | | | | | | Update links, content, and adding more examples to show how to run the generated .service files as root and non-root. Fix for #5497 Signed-off-by: Sujil02 <sushah@redhat.com>
* man page: add note about issue with SELinuxYuping Zuo2020-04-08
| | | | Signed-off-by: Yuping Zuo <zypA13510@users.noreply.github.com>
* Switch to using --time as opposed to --timeout to better match Docker.Daniel J Walsh2020-03-31
| | | | | | | We need to consistently use --time rather then --timeout throughout the code. Fix locations where timeout defaults are not set correctly as well. Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
* Merge pull request #5439 from ttys3/fixup-systemdgen-with-new-paramOpenShift Merge Robot2020-03-16
|\ | | | | systemd generator: force run container detached if CreateCommand has no detach param
| * force run container detached if container CreateCommand missing the detach param荒野無燈2020-03-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | the podman generated systemd service file has `Type=forking` service, so the command after `ExecStart=` should not run in front. if someone created a container and has the detach(`-d`) param missing like this ``` podman create --name ngxdemo -P nginxdemos/hello ``` and generate the file with `--new` param: ``` podman generate systemd --name --new ngxdemo ``` because `podman run xxx` has no `-d` param, so the container is not run in background and nerver exit. and systemd will fail to start the service: ``` sudo systemctl start container-ngxdemo.service Job for container-ngxdemo.service failed because a timeout was exceeded. See "systemctl status container-ngxdemo.service" and "journalctl -xe" for details. ``` Signed-off-by: 荒野無燈 <ttys3@outlook.com>
* | generate systemd: add `default.target` to INSTALLValentin Rothberg2020-03-09
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | When enabling a systemd service we can specify which target will start it by specifying it in the `[INSTALL]` section. In case of root, this is commonly set to `multi-user.target` which is used to start other essential system services such as the network manager, D-BUS and more. However, the `multi-user.target` is not enough on all systems, especially when running rootless and enabling user services. Multiple users have reported issues that there isn't even an attempt to start the service. Setting the INSTALL target to `default.target` will fix the rootless case. However, `default.target` may vary among systems. Fedora Workstation, for instance, sets the `default.target` to the graphical target (i.e., runlevel 5) while Fedora Server sets it to `multi-user.target` which is on runlevel 2 and hence way earlier in the startup sequence. As INSTALL allows for specifying multiple INSTALL targets, we can set it to `multi-user.target` to continue supporting existing workloads AND to `default.target` which MAY redundantly attempt to start it at a later point; effectively a NOP for the root case and essential for rootless. Fixes: #5423 Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
* podman-generate-systemd --newValentin Rothberg2020-01-09
| | | | | | | | | | | | | | | Add a --new flag to podman-generate-systemd to create a new container via podman-run instead of starting an existing container. Creating a new container presents the challenge to find a reverse mapping from a container to the CLI flags it can be created with. We are doing this via `(Container).Config.CreateCommand` field, which includes a copy of the process' command from procFS at creating time. This field may not be useful when the container was not created via the Podman CLI (e.g., via a Python script). Hence, we do not guarantee the correctness of the generated files. Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
* Update document formatting and packaging codeJhon Honce2019-10-31
* Refactored code and Makefile to support new docs layout * Removed some old code packaging code * Add Readme.md to document what we're doing Signed-off-by: Jhon Honce <jhonce@redhat.com> Signed-off-by: baude <bbaude@redhat.com>