Paul Holzinger

Results 836 comments of Paul Holzinger

EBUSY should only be the error if the netns is still mounted. However we umount directly before the remove call so that should not cause problems. The umount call uses...

I have no idea why it was added in the first place, maybe it is needed? Git blame goes all the way back to 8c52aa15f0e4927c0e570102efaa34dbe93d6156 which claims it needs MNT_DETATCH...

I see different errors posted here that are not the same! The original report says: `remove /run/user/3418/netns/netns-9965a9b5-facb-7fe9-44e3-f99ec7d69365: device or resource busy\""` Just to confirm I looked at `ip netns` which...

> Is this ([f39 rootless](https://api.cirrus-ci.com/v1/artifact/task/4841071981625344/html/int-podman-fedora-39-rootless-host-sqlite.log.html#t--Podman-kube-play-with-image-data--1)) the same error??? > > ``` > $ podman [options] stop --all -t 0 > time="2024-03-20T12:25:48-05:00" \ > level=error \ > msg="Unable to clean up...

FYI: The reason you see this more is because I enabled the warnings check in AfterEach() https://github.com/containers/podman/pull/18442 So previously we just didn't see them, in the logs above they all...

> Here's one with [a lot more context](https://api.cirrus-ci.com/v1/artifact/task/6685647379890176/html/int-podman-debian-13-rootless-host-sqlite.log.html#t--Podman-kube-generate-privileged-container--1), does that help? (Three total failures in this log, so be sure to Page-End then click on each individual failure) Not really...

@edsantiago Can you spin this patch through your testing PR: ```diff diff --git a/libpod/container_internal.go b/libpod/container_internal.go index 7f909b78d..ce5dbe0ef 100644 --- a/libpod/container_internal.go +++ b/libpod/container_internal.go @@ -1396,13 +1396,13 @@ func (c *Container) stop(timeout...

> [Sorry](https://api.cirrus-ci.com/v1/artifact/task/5065570012364800/html/int-podman-fedora-40-root-host-sqlite.log.html#t--Podman-start-podman-container-start-single-container-by-id--1) No need to be sorry, knowing that is good enough for me. And also the fact that this is fails on a simple podman create + start test...

> The same happened in #22922 so it's not just an one-off -- and obviously not a direct cause from updating the docs here. podman devs, does that ring a...

yes, although given it is used for userns=auto we may need to allocate a bigger range than `65536`, i.e. `1048576` (there plenty of free ids). Reason userns=auto tries to pick...