It is not used by anybody so we do not have to store these and can safe
some time by not having to generate it even if it is just ~500ms.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Two weeks ago we had a weird hang in the macos build job on the
persitent worker. The task just hang for an hour wasting time.
Most tests are fast so we do not need/want such high timeouts.
Therefore drop the default timeout to 20 minutes. The integration task
also should take under 20m so we can remove the longer timeout there as
well. Some system tests need a bit over 30m currently, timeout is set to
35m. For machine tests we use 30m on linux, 45m on windows and 35m on
macos to have some extra room there as machine tests have a much higher
run to run variance.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Generated at build time from troubleshooting.md. Purpose is
to ship an actual man page to end users.
Much more complicated than initial guess, because there was
a bug in my Makefile man page filtering, the sed expression
that cleans up markdown that does not translate to roff.
All I've done here is reorder some of the expressions,
stripping off https links *before* we process
podman man page links.
Signed-off-by: Ed Santiago <santiago@redhat.com>
This looks like a case of boilerplate error handling making it
too easy to miss a legitimately ignored error, which is annoying.
In a more featureful language most of the SQL code here could be
macros (at the very least, Rust would have forced us to handle
all error cases, not just the one seen here).
Found while looking through the Libpod DB code, no actual bug I
can think of associated with this.
Signed-off-by: Matt Heon <mheon@redhat.com>
Workaround (NOT A FIX) for pasta issue #23482, wherein
podman logs includes a waitpid: ESRCH warning. Consensus
seems to be that this is a bug in socat.
Signed-off-by: Ed Santiago <santiago@redhat.com>
The podman container cleanup process runs asynchronous and by the time
it gets the lock it is possible another podman process already did the
cleanup and then did a new init() to start it again. If the cleanup
process gets the lock there it will cause very weird things.
This can be observed in the remote start API as CI flakes.
Fixes#23754
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
This is very similar to commit 3280da0500, we cannot check the state
then unlock to then lock again and do the action. Everything must
happen under one lock. To fix this move the code into the HTTPAttach
function in libpod. The locking here is a bit weird because attach
blocks for the lifetime of attach which can be very long so we must
unlock before performing the attach.
Fixes#23757
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
We already exclude the build jobs this is causing the machine tasks to
fail as noticed in #23764. Given we do not need windows/macos testing
for RHEL we have to skip them there.
While we try to only use only_if the problem here is that we would need
to duplicate the big only_if_machine_test string and work the rhel
condition into it which doesn't work with the current logic either so we
would need to change the logic flow there which then doesn't work with
our cirrus_yaml_test.py selftest. Therefore I think using skip here is
easier.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
When we use passthrough logging and the --rmi option should not try to
delete the image right away. Simply speak passthough only means do not
print the cotnainer id but we should never try to delete the image here
as this will be done in the cleanup process.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Since commit 458ba5a8af the cleanup process now removes the image as
well, thus the removal is racy and it will cause an error here.
The code tried to ignore the error with errors.Is() but this never works
across the remote API. However the API already has a ignore option so
juts use that and fix the error message so that we can easily find the
root cause and I do not have to guess where the log was written.
Fixes#23719
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
There seems to be one change[1] which breaks our tests, the route Dst field
is no longer nil for a default route but rather the empty ipnet, i.e.
0.0.0.0/0 and ::/0 so fix that up in our code.
[1] https://github.com/vishvananda/netlink/pull/852
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Example:
DefaultEnvironment="VAR1=word1 word2" VAR2=word3 "VAR3=word 5 6"
Sets three variables "VAR1", "VAR2", "VAR3".
Double quote is not escaped, as there is no chance it appears in a proxy value. User can still espace it if really necessary
Signed-off-by: Philippe Martin <phmartin@redhat.com>
Belated followup to #21965.
All this time, we've been creating a socket and running
podman-remote --url /path/to/socket
This dates back to varlink. Remember varlink?
There's no need for it. Let's run podman system service
with no args. That's a more realistic test, and it makes
our logs cleaner as a bonus.
Signed-off-by: Ed Santiago <santiago@redhat.com>
