summaryrefslogtreecommitdiff
path: root/pkg/systemdgen/systemdgen.go
Commit message (Collapse)AuthorAge
* systemdgen: specify --cgroups=disabled-conmon for --newGiuseppe Scrivano2020-01-16
| | | | Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
* systemdgen: add --ignore flag to generic servicesValentin Rothberg2020-01-16
| | | | | | | | | | | | | | | | | The --ignore flag lets Podman ignore errors when a specified container does not exist (anymore). That's a nice addition to generic services generated via the --new flag. Those services create new containers and can hence allows user to manually remove a container; may it only be by accident. The important part of using the --ignore flag is that Podman will exit 0 which plays nicer with most restart policies; a non-zero exit may yield systemd to restart the entire service which is arguably wrong if the user manually deletes the container. If desired, users can still alter the generated files. 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>
* generate systemd: support pods and geneartig filesValentin Rothberg2019-08-21
| | | | | | | | | | | Support generating systemd unit files for a pod. Podman generates one unit file for the pod including the PID file for the infra container's conmon process and one unit file for each container (excluding the infra container). Note that this change implies refactorings in the `pkg/systemdgen` API. Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
* Do not hardcode podman binary location in generate systemd.Danila Kiver2019-07-07
| | | | | | | | It is not correct to rely on specific location of the podman binary. In most cases it is /usr/bin/podman, but sometimes is not (e.g. in system tests). Use /proc/self/exe instead of hardcoded path. Signed-off-by: Danila Kiver <danila.kiver@mail.ru>
* Use conmon pidfile in generated systemd unit as PIDFile.Danila Kiver2019-07-04
| | | | | | | | | | | By default, podman points PIDFile in generated unit file to non-existent location. As a result, the unit file, generated by podman, is broken: an attempt to start this unit without prior modification results in a crash, because systemd can not find the pidfile of service's main process. Fix the value of "PIDFile" and add a system test for this case. Signed-off-by: Danila Kiver <danila.kiver@mail.ru>
* Generate systemd unit files for containersbaude2019-05-02
the podman generate systemd command will generate a systemd unit file based on the attributes of an existing container and user inputs. the command outputs the unit file to stdout for the user to copy or redirect. it is enabled for the remote client as well. users can set a restart policy as well as define a stop timeout override for the container. Signed-off-by: baude <bbaude@redhat.com>