When the rootlessport process is started the stdout/stderr are attached
to the podman process. However once everything is setup podman exits and
when the rootlessport process tries to write to stdout it will fail with
SIGPIPE. The code handles this signal and puts /dev/null to stdout and
stderr but this is not robust. I do not understand the exact cause but
sometimes the process is still killed by SIGPIPE. Either go lost the
signal or the process got already killed before the goroutine could
handle it.
Instead of handling SIGPIPE just set /dev/null to stdout and stderr
before podman exits. With this there should be no race and no way to
run into SIGPIPE errors.
[NO TESTS NEEDED]
Fixes#11248
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Originally, Podman would unconditionally remove volumes from the
DB, even if they failed to be removed from the volume plugin;
this was a safety measure to ensure that `volume rm` can always
remove a volume from the database, even if the plugin is
misbehaving.
However, this is a significant deivation from Docker, which
refuses to remove if the plugin errors. These errors can be
legitimate configuration issues which the user should address
before the volume is removed, so Podman should also use this
behaviour.
Fixes#11214
Signed-off-by: Matthew Heon <mheon@redhat.com>
These tests were originally enabled in a situation where CI provided
false-positive results. Now that has been corrected, these tests all
fail under a CGv1 container environment with the error:
```
Error: unable to load cgroup at
/machine.slice/libpod-e4f...086.scope/libpod_parent/libpod-fbd...425:
cgroup deleted
```
This commit simply disables the tests under this specific environment.
Signed-off-by: Chris Evich <cevich@redhat.com>
This becomes a problem on hosts with upgraded policies. Ref:
https://github.com/containers/podman/issues/10522
Also, made a small change to compose-test setup to reduce runtime.
Signed-off-by: Chris Evich <cevich@redhat.com>
This reverts commit 404d5edb1557e3d2cb255d38bd89274586c4c100.
The replacement (updated) images include a fix for:
https://github.com/containers/common/issues/631
Also minor update to an unrelated FIXME comment.
Signed-off-by: Chris Evich <cevich@redhat.com>
When setting path names in the build context archive, convert path names
to use forward slashes, as is normal for those archives, so that
directory hierarchies archived on Windows hosts extract correctly
everywhere.
Not really sure how to run the remote client in CI on a system that uses
`\` as a path separator, which is where this error crops up, so
[NO TESTS NEEDED]
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
When playing a kube YAML file, it can be desirable to be able to build
an image on the fly. This is good for development of an image and YAML
files and somewhat mocks what compose does.
Signed-off-by: Brent Baude <bbaude@redhat.com>
I attempted to run the tests in a loop (one VM) but it fails with:
```
not ok 8 exec
(from function `is' in file test/upgrade/../system/helpers.bash, line
474,
in test file test/upgrade/test-upgrade.bats, line 222)
`is "$output" "$RANDOM_STRING_1" "exec into myrunningcontainer"'
failed
/var/tmp/go/src/github.com/containers/podman/bin/podman exec
myrunningcontainer cat /var/www/index.txt
time="2021-08-17T13:34:21-05:00" level=warning msg="Failed to add
conmon to systemd sandbox cgroup: Invalid unit name '/libpod_parent'"
uagHtpYnA47bkz3
/vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
| FAIL: exec into myrunningcontainer
| expected: 'uagHtpYnA47bkz3'
| actual: 'time="2021-08-17T13:34:21-05:00" level=warning
msg="Failed to add conmon to systemd sandbox cgroup: Invalid unit name
'/libpod_parent'"'
| > 'uagHtpYnA47bkz3'
\^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
Since the current implementation doesn't reproduce this error, the
change isn't worth the cost of debugging/fixing. OTOH, making the job
only run from the daily cirrus-cron builds is a simple change.
Signed-off-by: Chris Evich <cevich@redhat.com>
Dealing with os.Signal channels seems more like an art than science
since signals may get lost. os.Notify doesn't block on an unbuffered
channel, so users are expected to know what they're doing or hope for
the best.
In the recent past, I've seen a number of flakes and BZs on non-amd64
architectures where I was under the impression that signals may got
lost, for instance, during stop and exec.
[NO TESTS NEEDED] since this is art.
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
Depending how the user logs in to the root account, XDG_RUNTIME_DIR is
set to /run/user/0 or it is unset. For conmon we already set it always
to an empty string. The inconsistency is causing issues for the dnsname
plugin. To fix it unset XDG_RUNTIME_DIR for the podman process.
[NO TESTS NEEDED]
Fixes#10806Fixes#10745
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
When a host uses systemd-resolved but not the resolved stub resolver the
following symlinks are created: `/etc/resolv.conf` ->
`/run/systemd/resolve/stub-resolv.conf` -> `/run/systemd/resolve/resolv.conf`.
Because the code uses filepath.EvalSymlinks we put the new resolv.conf
to `/run/systemd/resolve/resolv.conf` but the `/run/systemd/resolve/stub-resolv.conf`
link does not exists in the mount ns.
To fix this we will walk the symlinks manually until we reach the first
one under `/run` and use this for the resolv.conf file destination.
This fixes a regression which was introduced in e73d4829900c.
Fixes#11222
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
