cmd, test/system: Retain exit codes when forwarding to host #1534
Conversation
|
Build failed. ✔️ unit-test SUCCESS in 5m 28s |
debarshiray
force-pushed
the
wip/rishi/cmd-forward-stderr-02
branch
from
1842899
to
035806c
Compare
|
Build failed. ✔️ unit-test SUCCESS in 5m 26s |
This will make it easier to propagate the exit codes of subordinate processes through an exitError instance, when toolbox(1) is invoked inside a container, and invocation is forwarded to the host. Cobra doesn't honour the root command's SilenceErrors, if an error occurred when parsing the command line for a command, even though the command was found. However, Cobra does honour SilenceErrors, if the error occurred afterwards. Therefore, to avoid setting SilenceErrors in each and every command, it was set in the PersistentPreRunE hook (ie., preRun), which is called after all command line parsing has been successfully completed. containers#957
debarshiray
force-pushed
the
wip/rishi/cmd-forward-stderr-02
branch
from
035806c
to
1a3f4ff
Compare
|
Build succeeded. ✔️ unit-test SUCCESS in 5m 34s |
|
Build failed. ✔️ unit-test SUCCESS in 5m 38s |
Some changes by Debarshi Ray. containers#957 containers#1052
debarshiray
force-pushed
the
wip/rishi/cmd-forward-stderr-02
branch
from
e3ff9ba
to
fa24660
Compare
The test suite uses its own separate local container/storage store to isolate itself from the default store, so that the tests' interactions with containers and images don't affect anything else. This is done by using the CONTAINERS_STORAGE_CONF environment variable [1] to specify a separate storage.conf(5) file [2]. Therefore, when running the test suite, the CONTAINERS_STORAGE_CONF environment variable must be preserved when forwarding toolbox(1) invocations inside containers to the host. Otherwise, the initial toolbox(1) invocation on the host and the forwarded invocation running on the host won't use the same local container/storage store. This problem only impacts test cases that cover toolbox(1) code paths that invoke podman(1). [1] https://docs.podman.io/en/latest/markdown/podman.1.html [2] https://manpages.debian.org/testing/containers-storage/containers-storage.conf.5.en.html containers#957 containers#1052
|
Build succeeded. ✔️ unit-test SUCCESS in 5m 34s |
|
Build succeeded. ✔️ unit-test SUCCESS in 5m 41s |
The lines were getting too wide to fit within a vertical 1080x1920 display. Therefore, restrict them to 120 characters per line. Fallout from f8e21a3 containers#1534
|
Build succeeded. ✔️ unit-test SUCCESS in 5m 32s |
When 'toolbox run' is invoked on the host, an exit code of 126 from 'podman exec' means that the specified command couldn't be invoked because it's not an executable. eg., the command was actually a directory. Note that this doesn't mean that the command couldn't be found. That's denoted by exit code 127. Secondly, Toolbx containers always have an executable toolbox(1) binary at /usr/bin/toolbox and it's assumed that /usr/bin is always part of the PATH environment variable. When 'toolbox run toolbox ...' is invoked, the inner toolbox(1) invocation will be forwarded back to the host by the Toolbx container's /usr/bin/toolbox, which is always present as an executable. Hence, if the outer 'podman exec' on the host fails with an exit code of 126, then it doesn't mean that the container didn't have a working toolbox(1) executable, but that some subordinate process started by the container's toolbox(1) failed with that exit code. Therefore, handle this as a special case to avoid showing an extra error message. Otherwise, it leads to: $ toolbox run toolbox run /etc bash: line 1: /etc: Is a directory bash: line 1: exec: /etc: cannot execute: Is a directory Error: failed to invoke command /etc in container fedora-toolbox-40 Error: failed to invoke command toolbox in container fedora-toolbox-40 $ echo "$?" 126 Instead, it will now be: $ toolbox run toolbox run /etc bash: line 1: /etc: Is a directory bash: line 1: exec: /etc: cannot execute: Is a directory Error: failed to invoke command /etc in container fedora-toolbox-40 $ echo "$?" 126 containers#957 containers#1052
When 'toolbox run' is invoked on the host, an exit code of 127 from
'podman exec' means either that the specified command couldn't be found
or that the working directory didn't exist. The only way to tell these
two scenarios apart is to actually look inside the container.
Secondly, Toolbx containers always have an executable toolbox(1) binary
at /usr/bin/toolbox and it's assumed that /usr/bin is always part of the
PATH environment variable.
When 'toolbox run toolbox ...' is invoked, the inner toolbox(1)
invocation will be forwarded back to the host by the Toolbx container's
/usr/bin/toolbox, which is always present as an executable. Hence, if
the outer 'podman exec' on the host fails with an exit code of 127,
then it doesn't mean that the container didn't have a toolbox(1)
executable, but that some subordinate process started by the container's
toolbox(1) failed with that exit code.
Therefore, handle this as a special case to avoid losing the exit code.
Otherwise, it leads to:
$ toolbox run toolbox run non-existent-command
bash: line 1: exec: non-existent-command: not found
Error: command non-existent-command not found in container
fedora-toolbox-40
$ echo "$?"
0
Instead, it will now be:
$ toolbox run toolbox run non-existent-command
bash: line 1: exec: non-existent-command: not found
Error: command non-existent-command not found in container
fedora-toolbox-40
$ echo "$?"
127
containers#957
containers#1052
|
Build succeeded. ✔️ unit-test SUCCESS in 5m 41s |
|
Build succeeded. ✔️ unit-test SUCCESS in 5m 28s |
Some changes by Debarshi Ray.
#957
#1052