Debug for #23913, I though if we have no idea which process is nuking
the volume then we need to figure this out. As there is no reproducer
we can (ab)use the cleanup tracer. Simply trace all unlink syscalls to
see which process deletes our special named volume. Given the volume
name is used as path on the fs and is deleted on volume rm we should
know exactly which process deleted it the next time hopefully.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Setup2() calls Setup() so they are both the same thing, the idea was to
keep Setup2() around in c/common for a bit to avoid breaking changes
during our regular vendoring. Now just use Setup() so we can get rid of
Setup2() in c/common.
a7415c3eab
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
I had a few cases where this is super handy in CI and if I can access the
link without one extra click it safes me some time and hopefully makes
it more discoverable for other to see how useful it can be sometimes.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
In coreos /mnt is a symlink to /vat/mnt and systemd does not like do use
the symlink for some reason. Simply fix the example to use /Users which
now works as we always create the directories even on /.
Fixes#24281
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
It is part of the release process yet everybody ignores this. I really
should look into automating this instead.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Nobody is looking into this anyway and it just clutters the logs and
will cause confusion for readers. If some day someone wants to fix the
macos IO bugs they can add this back.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
- rework the slirp4netns section into a general 'Networking configuration' one
- integrate pasta as the new default tool for rootless networking since v5.0
- touch upon the user-facing differences between the two available backends and provide
links to further documentation, including how to choose between one and the other and
how to install them
Fixes: #24393
Signed-off-by: Bastien Traverse <neitsab@esrevart.net>
The cgroup.Stat() operation is not atomic, so it's possible that the
cgroup is removed during the Stat() call. Catch specific errors that
can occur when the cgroup is missing and validate the existence of the
cgroup path.
If the cgroup is not found, return a more specific error indicating
that the container has been removed.
Closes: https://github.com/containers/podman/issues/23789
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
In preparation for maybe some day being able to run build tests
in parallel.
SUPER IMPORTANT NOTE! BUILD TESTS CANNOT BE PARALLELIZED YET!
buildah, when run in parallel, barfs with:
race: parallel builds: copying...committing...creating... layer not known
Until this is fixed, podman-build can never be run in parallel.
See https://github.com/containers/buildah/issues/5674
This PR is simply cleaning things up so, if/when that day comes,
the ensuing parallelize PR will be short & sweet.
Signed-off-by: Ed Santiago <santiago@redhat.com>
Ygal Blum
openshift-merge-bot[bot]
renovate[bot]
Maximilian Hueter
Paul Holzinger
Anders F Björklund
Bastien Traverse
Giuseppe Scrivano
shenpengfeng
Ed Santiago