There are two fields I'm worried about: shared namespaces and pod
containers. Both are generated via loops over maps and are thus
non-deterministic in ordering. Throw a sort on each to fix the
order so we can actually diff `podman pod inspect` output.
Signed-off-by: Matt Heon <mheon@redhat.com>
- Update documentation: Differentiate `unless-stopped` from `always` - containers stopped by the user before a reboot will not restart.
- Add `should-start-on-boot` filter: Identify containers that require a restart after a system reboot.
- Update command documentation: Add `restart-policy` and `label!` filters to the documentation for container commands (rm, ps, start, stop, pause, unpause, restart).
- Add `restart-policy` and `shoud-start-on-boot` to completions.
- Update service: Update `podman-restart.service` to use the `needs-restart=true` filter.
- Preserve state: Preserve the `StoppedByUser` state across reboots.
- Update API: Add a `ShouldStartOnBoot()` method to the Container API.
- Update documentation: Add descriptions for the `should-start-on-boot` filter.
Fixes: https://issues.redhat.com/browse/RHEL-129405
Fixes: https://github.com/containers/podman/issues/20418
Signed-off-by: Jan Rodák <hony.com@seznam.cz>
<MH: Fixed cherry-pick conflicts>
Signed-off-by: Matt Heon <matthew.heon@pm.me>
Fixes: #26588
For use cases like HPC, where `podman exec` is called in rapid succession, the standard exec process can become a bottleneck due to container locking and database I/O for session tracking.
This commit introduces a new `--no-session` flag to `podman exec`. When used, this flag invokes a new, lightweight backend implementation that:
- Skips container locking, reducing lock contention
- Bypasses the creation, tracking, and removal of exec sessions in the database
- Executes the command directly and retrieves the exit code without persisting session state
- Maintains consistency with regular exec for container lookup, TTY handling, and environment setup
- Shares implementation with health check execution to avoid code duplication
The implementation addresses all performance bottlenecks while preserving compatibility with existing exec functionality including --latest flag support and proper exit code handling.
Changes include:
- Add --no-session flag to cmd/podman/containers/exec.go
- Implement lightweight execution path in libpod/container_exec.go
- Ensure consistent container validation and environment setup
- Add comprehensive exit code testing including signal handling (exit 137)
- Optimize configuration to skip unnecessary exit command setup
Signed-off-by: Ryan McCann <ryan_mccann@student.uml.edu>
Signed-off-by: ryanmccann1024 <ryan_mccann@student.uml.edu>
Signed-off-by: SanjayReddy91 <gamerzdamnyt1234@gmail.com>
test: add test to check if SQLite DB config change will mitigate race condition when multiple podman process start at once.
Signed-off-by: SanjayReddy91 <gamerzdamnyt1234@gmail.com>
test: Check to ensure only one row was created in DBConfig table.
Signed-off-by: SanjayReddy91 <gamerzdamnyt1234@gmail.com>
test: Changed no of processes started at once to 20.
Signed-off-by: SanjayReddy91 <gamerzdamnyt1234@gmail.com>
test: rc reset to 0 to not affect second part of the test, db path is no longer hardcoded in test case.
Signed-off-by: SanjayReddy91 <gamerzdamnyt1234@gmail.com>
test: Reverted test case.
Signed-off-by: SanjayReddy91 <gamerzdamnyt1234@gmail.com>
lint: removed trailing whitespaces.
Signed-off-by: SanjayReddy91 <gamerzdamnyt1234@gmail.com>
By default, systemd sets a limit of how many times a service can start,
which means that if you have a healthcheck that runs more often than the
limits, systemd will refuse to start it with a message like "Start request
repeated too quickly." emitted to the journal.
Signed-off-by: Winter M <winter@antithesis.com>
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
This is gated behind a new option in `podman system migrate`,
`--migrate-db`.
The basic logic is simple:
* Podman is already configured to use BoltDB
* Open a new, fresh SQLite database to write into
* Migrate all database contents as they exist in BoltDB, to
SQLite.
** Do this as simply as possible: grab the object from the old DB
and write it into the new DB using the standard Add and Save
functions.
* Set the new database in the Runtime, close the old one.
* Move the old database file so it won't be reused
* Show a warning if the user explicitly configured BoltDB in
containers.conf
Our ability to test complex migration scenarios is limited, but
this should handle simple migrations easily.
Fixes#27628
Signed-off-by: Matt Heon <matthew.heon@pm.me>
There are two fields I'm worried about: shared namespaces and pod
containers. Both are generated via loops over maps and are thus
non-deterministic in ordering. Throw a sort on each to fix the
order so we can actually diff `podman pod inspect` output.
Signed-off-by: Matt Heon <mheon@redhat.com>
The code checks for isPathOnVolume and isPathOnMount so we can just use
the SecureJoin here directly to check for path existance.
Then instead of walking symlinks and trying to guess if they are on a
mount just assume if it is a link (path is different from the normal
joined one) then don't error out early and let the OCI runtime deal with
it. The runtime does produce a less readable error but it still fails
and we have much less fragile code.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
MkdirAll can fail with EEXIST when the path is a symlink and the target
doesn't exist. As such we should ignore the error.
Note there is something fundemantal wrong here with the path access as
it is following the symlink to the host, however it is only for a
stat() so it is not an security issue here.
Fixes: 637c264e2e ("fix issues found by nilness")
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
The old location is deprecated and has been removed in v0.6.0 even. I
did this as extra commit to make cherry-picking easier.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Signed-off-by: tomsweeneyredhat <tsweeney@redhat.com>
We started logging this in 5.6. In 5.7, we up to a warning. The
upcoming 5.8 will up the warnings further to errors.
Required as we're removing BoltDB support in 6.0 next Spring.
Signed-off-by: Matt Heon <matthew.heon@pm.me>
Problem: While removing cgroupsv1 code, I noticed my neovim Go config
automatically changed fileperms to the new octal format and I didn't
want that polluting my diffs.
Decision: I thought it best to switch to the new octal format in a dedicated PR.
Action:
- Cursor switched to new octal format for all fileperm ocurrences in Go
source and test files.
- vendor/, docs/ and non-Go files were ignored.
- Reviewed manually.
Ref: https://go.dev/ref/spec#Go_1.13
Signed-off-by: Lokesh Mandvekar <lsm5@redhat.com>
Include an explicit container state check. Otherwise the
containers/stats endpoint will return all-zero stats for a stopped
container even when in non-streaming mode, which breaks some consumers
of the API, particularly nomad's podman driver.
Implement the interface by just returning the number of host CPUs. A
bit more sophisticated would be to fetch the jail's cpuset, but it's not
very important for now.
Signed-off-by: Mark Johnston <mark.johnston@klarasystems.com>
Using golang.org/x/tools/gopls/internal/analysis/modernize/cmd/modernize
+ some manual cleanup in libpod/lock/shm/shm_lock_test.go as it
generated an unused variable
+ restored one removed comment
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
The `cleanupExecBundle` function was only meant to be called on a
locked container, as it does some state mutation operations. It
also has a timed wait (if the directory is busy and can't be
removed yet, give it a few milliseconds) in which it deliberately
yields the lock to not block the container for that time.
The `healthCheckExec()` function calls `cleanupExecBundle` out of
a `defer` block. This is after the `defer c.lock.Unlock()` so it
fires afterwards when the function returns, so we're normally
fine - the container is still locked when our defer runs. The
problem is that `healthCheckExec()` also unlocks the container
during the expensive exec operation, and can actually fail and
return while not holding the lock - meaning our `defer` can fire
on an unlocked container, leading to a potential double unlock
in `cleanupExecBundle`.
We could, potentially, re-lock the container after the exec
occurs, but we're actually waiting for a `select` to trigger to
end the function, so that's not a good solution. Instead, just
re-lock (if necessary) in the defer, before invoking
`cleanupExecBundle()`. The `defer c.lock.Unlock()` will fire
right after and unlock after us.
Fixes#26968
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
At one point, we created multiple jails per container in order to enable
network configuration from outside the container jail. On FreeBSD 14.x
and later this is not necessary and there is only one jail per
container. In this case, return the correct jail name.
Signed-off-by: Mark Johnston <mark.johnston@klarasystems.com>
FreeBSD's ps ignores -J if -a is specified, so "podman top" would
effectively just run ps -a, not terribly useful. But there's no need to
specify -a when specifying a selector such as -J (or -G or -U, etc.).
Signed-off-by: Mark Johnston <mark.johnston@klarasystems.com>
Starting with runc 1.3.0 it errors when we pass unknown mount options to
the runtime, the copy/nocopy options are specific to podman when we
mount the volume and are not valid mount options for the runtime.
Fixes: #26938
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Starting with runc 1.3.0 it errors when we pass unknown mount options to
the runtime, the volume-opt options are specifc to the volume we create
and should not be passed to the mount in the oci spec.
Fixes: #26938
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
In the journald driver there is a bug where the network event
attributes are not preserved. This causes the network driver to be
missing and that in turn causes the ToHumanReadable() function to print
an empty line. Fix it by making sure we preserve the network driver in
the event attributes.
Fixes: https://issues.redhat.com/browse/RHEL-109790
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Right now, only log-level=info, so not shown by default. We can
continue to up this in subsequent releases to convince folks of
the urgency of switching.
Resolves https://issues.redhat.com/browse/RUN-3343
Signed-off-by: Matt Heon <mheon@redhat.com>
Added log_path variable in containers/common, User sets default log path in containers.conf under the `[containers]` section.
The directory has to exist beforehand. Container logs go under this directory, sub-directories named with the container id
and inside the sub-directory a ctr.log file will be created where the container logs for the corresponding container will go.
This path can be overridden by using the `--log-opt` flag.
Signed-off-by: Joshua Arrevillaga <2004jarrevillaga@gmail.com>
When conmon was killed podman rm -f currently fails but running it again
then works which doesn't really makes sense. We should properly remove
the contianer even if conmon is dead.
In fact the code already handles ErrConmonDead as stop error when we
remove the container but this error was never thrown anywhere. To fix
this throw ErrConmonDead instead of ErrInternal because that is not an
intenral error if something else killed conmon.
With this we can correctly cleanup and remove the container. The fact
that this works on the first try is important for quadlet units as they
only run the ExecStopPost= command once to remove it.
Fixes: #26640
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
When generating Conmon's command line, we read containers.conf to
get log_size_max and used it if the container didn't override it.
However, `podman inspect` only reads from the container's own
config, and ignores containers.conf. Unify the way we determine
maximum log size with a single function and use it for both
inspect and containers.conf, and add a test for this behavior.
Fixes https://issues.redhat.com/browse/RHEL-96776
Signed-off-by: Matt Heon <mheon@redhat.com>
