| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Don't hardcode /usr/bin/podman in unit files: instead, use
template files with a path replaced at install time.
Because 'make' can be invoked repeatedly, with different
PREFIX, do not leave the generated files behind in our
work directory: wipe them immediately after install.
To get this to work, fix a longstanding bug in podman.spec.in,
a PREFIX that should've been DESTDIR.
Side note: #7023 made contrib/systemd/user a symlink
to .../system but did not update paths in Makefile.
The unrelated-looking path change you see here is
a belated correction for that.
Fixes: #10787
Signed-off-by: Ed Santiago <santiago@redhat.com>
|
| |
|
|
|
|
|
|
|
| |
Require the network to be online in all (generated) systemd units to
make sure that containers and Podman run only after the network has been
fully configured.
Fixes: #10655
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This makes sure, that the podman auto-update is not executed exactly at midnight for the same time always.
If many things do the same and many services use this keyword and react at midnight, this can cause a lot of stress to a server.
Thus, this adds a 900s/15min delay.
As [the arch wiki says](https://wiki.archlinux.org/title/Systemd/Timers#Realtime_timer):
> Special event expressions like daily and weekly refer to specific start times and thus any timers sharing such calendar events will start simultaneously. Timers sharing start events can cause poor system performance if the timers' services compete for system resources. The RandomizedDelaySec option in the [Timer] section avoids this problem by randomly staggering the start time of each timer. See systemd.timer(5).
Signed-off-by: rugk <rugk+git@posteo.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Extend the systemd auto-update service to prune images after an update
has run. As reported by a user [1], auto updates can over time cause
the disk to run out of space. With Edge being a target use case, we
need to make sure that systems can run without much supervision, so
let's make sure to run `podman image prune` to clean up dangling images.
[1] https://twitter.com/r_isc_y/status/1388981737011793921
Fixes: #10190
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
|
| |
|
|
| |
Signed-off-by: Vilgot Fredenberg <vilgot@fredenberg.xyz>
|
|
|
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>
|
