I've seen a runc zombie process hanging around, it is caused by not
cleaning up the "$OCI status" process. Also adjust another location
that has the same issue.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
when doing stats -a|--all, if you have non-running containers, we should
not error on not being able to get information like PID, etc on them.
Signed-off-by: baude <bbaude@redhat.com>
When doing rm, we now parallelize the actual conainter deletions so they
can complete faster. This speeds up operations like rm -a.
Signed-off-by: baude <bbaude@redhat.com>
Running 'podman port -l' on a system without any containers created
gives:
$ podman port -l
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0xf3cef1]
goroutine 1 [running]:
github.com/containers/libpod/libpod.(*Container).State(0x0, 0x0, 0x0, 0x0)
/share/go/src/github.com/containers/libpod/libpod/container.go:658 +0x41
main.portCmd(0xc420094580, 0x0, 0x0)
/share/go/src/github.com/containers/libpod/cmd/podman/port.go:118 +0x406
This fixes it by making sure the variable 'containers' is nil and not [<nil>].
Signed-off-by: Adrian Reber <areber@redhat.com>
An invalid GCE value is being passed to packer, preventing it from
building VM images. Fix this, and centralize the definition of the
image name suffix by setting it at ``setup_environment.sh`` call-time,
rather encoding inside packer's `libpod_images.json`. This makes
the value available for use by other scripts.
Also, switch the unique component of the name, to be based on the
commit-sha being tested. This will improve traceability, since the git
history is more permanent than the `CIRRUS_BUILD_ID` env. var. The
later is subject to log-rotation, destroying evidence of the images
source state.
Signed-off-by: Chris Evich <cevich@redhat.com>
Add a naive python script that's able to connect to IRC and send a
single line of text to the #podman channel. Wrap this in a new
library function to ensure nick-name collisions are unlikely.
Signed-off-by: Chris Evich <cevich@redhat.com>
We already have functions for retrieving the container's CGroup
path, so use them instead of manually generating a path.
Signed-off-by: Matthew Heon <matthew.heon@gmail.com>
