There have been some python-podman flakes observed across multiple CI
systems. Support capturing a VM for further investigation in the
event of a non-zero exit. This is done by printing a warning message
and delaying script-exit for a long time. Hopefully a human will notice
and have an opportunity to enable deletion-protection on the VM.
Signed-off-by: Chris Evich <cevich@redhat.com>
* Add support for pod -- create, inspect, kill, pause, ps, rm,
restart, start, stop, top, unpause
* Update pylintrc to better reflect pep8 code standards
* Fix various pylint reported errors
* Refactor code that determines screen width to no longer
require initializing curses. Improved start up time and
pushing data blob down ssh tunnel.
* Correct pod-create man page, cgroupparent not boolean
* Abort integration tests if podman service fails to start
Signed-off-by: Jhon Honce <jhonce@redhat.com>
If someone runs podman as a user (uid) that is not defined in the container
we want generate a passwd file so that getpwuid() will work inside of container.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
We were encountering sync issues with the map, so swap to a
thread-safe channel and convert into a map when we output
Signed-off-by: Matthew Heon <matthew.heon@gmail.com>
As of now, there is no way to debug podman clean up processes.
They are started by conmon with no stdout/stderr and log nowhere.
This allows us to actually figure out what is going on when a
cleanup process runs.
Signed-off-by: Matthew Heon <matthew.heon@gmail.com>
Add the --ip flag back with bash completions. Manpages still
missing.
Add plumbing to pass appropriate the appropriate option down to
libpod to connect the flag to backend logic added in the previous
commits.
Signed-off-by: Matthew Heon <matthew.heon@gmail.com>
the issue is caused by the Go Runtime that messes up with the process
signals, overriding SIGSETXID and SIGCANCEL which are used internally
by glibc. They are used to inform all the threads to update their
stored uid/gid information. This causes a hang on the set*id glibc
wrappers since the handler installed by glibc is never invoked.
Since we are running with only one thread, we don't really need to
update other threads or even the current thread as we are not using
getuid/getgid before the execvp.
Closes: https://github.com/containers/libpod/issues/1625
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Prior, we were stopping containers serially. So if a container had a default
timeout of 10 seconds and there were five containers being stopped, the operation
would take roughly 50 seconds. If we stop these containers in parallel, the operation
should be roughly 10 seconds and change which is a significant speed up at scale.
Signed-off-by: baude <bbaude@redhat.com>
