summaryrefslogtreecommitdiff
path: root/pkg/systemd/generate
Commit message (Collapse)AuthorAge
* Fixup issues found by golintDaniel J Walsh2020-06-10
| | | | Signed-off-by: Daniel J Walsh <dwalsh@redhat.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>
* auto updatesValentin Rothberg2020-03-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support to auto-update containers running in systemd units as generated with `podman generate systemd --new`. `podman auto-update` looks up containers with a specified "io.containers.autoupdate" label (i.e., the auto-update policy). If the label is present and set to "image", Podman reaches out to the corresponding registry to check if the image has been updated. We consider an image to be updated if the digest in the local storage is different than the one of the remote image. If an image must be updated, Podman pulls it down and restarts the container. Note that the restarting sequence relies on systemd. At container-creation time, Podman looks up the "PODMAN_SYSTEMD_UNIT" environment variables and stores it verbatim in the container's label. This variable is now set by all systemd units generated by `podman-generate-systemd` and is set to `%n` (i.e., the name of systemd unit starting the container). This data is then being used in the auto-update sequence to instruct systemd (via DBUS) to restart the unit and hence to restart the container. Note that this implementation of auto-updates relies on systemd and requires a fully-qualified image reference to be used to create the container. This enforcement is necessary to know which image to actually check and pull. If we used an image ID, we would not know which image to check/pull anymore. Fixes: #3575 Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
* fix systemd generate testsValentin Rothberg2020-03-16
| | | | | | Add the `default.target` to the failing tests. Signed-off-by: Valentin Rothberg <rothberg@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>
* generate systemd: remove leading slashesValentin Rothberg2020-03-05
| | | | | | | | | Remove leading slashes from the run-dir paths. It was meant to make it explicit that we're dealing with an absolute path but user feedback has shown that most are aware. It also cleans up the path in the systemctl status output. Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
* generate systemd: add network dependenciesValentin Rothberg2020-03-03
| | | | | | | | Add network dependencies to generated systemd services to allow for enabling them at system startup and have a working network if needed. Fixes: #4130 Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
* Fix handler and systemd activation errorsJhon Honce2020-02-17
On panic from handler: log warning and stack trace, report InternalServerError to client When using `podman system service` make determining the listening endpoint deterministic. // When determining _*THE*_ listening endpoint -- // 1) User input wins always // 2) systemd socket activation // 3) rootless honors XDG_RUNTIME_DIR // 4) if varlink -- adapter.DefaultVarlinkAddress // 5) lastly adapter.DefaultAPIAddress Fixes #5150 Fixes #5151 Signed-off-by: Jhon Honce <jhonce@redhat.com>