aboutsummaryrefslogtreecommitdiff
path: root/pkg/hooks/exec/exec.go
Commit message (Collapse)AuthorAge
* first pass of corrections for golangci-lintbaude2019-07-10
| | | | Signed-off-by: baude <bbaude@redhat.com>
* pkg/hooks/exec: Include failed command in hook errorsW. Trevor King2019-01-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For example: $ cat /etc/containers/oci/hooks.d/test.json { "version": "1.0.0", "hook": { "path": "/bin/sh", "args": ["sh", "-c", "echo 'oh, noes!' >&2; exit 1"] }, "when": { "always": true }, "stages": ["precreate"] } $ podman run --rm docker.io/library/alpine echo 'successful container' error setting up OCI Hooks: executing [sh -c echo 'oh, noes!' >&2; exit 1]: exit status 1 The rendered command isn't in in the right syntax for copy/pasting into a shell, but it should be enough for the user to be able to locate the failing hook. They'll need to know their hook directories, but with the previous commits requiring explicit hook directories it's more likely that the caller is aware of them. And if they run at a debug level, they can see the lookups in the logs: $ podman --log-level=debug --hooks-dir=/etc/containers/oci/hooks.d run --rm docker.io/library/alpine echo 'successful container' 2>&1 | grep -i hook time="2018-12-02T22:15:16-08:00" level=debug msg="reading hooks from /etc/containers/oci/hooks.d" time="2018-12-02T22:15:16-08:00" level=debug msg="added hook /etc/containers/oci/hooks.d/test.json" time="2018-12-02T22:15:16-08:00" level=debug msg="hook test.json matched; adding to stages [precreate]" time="2018-12-02T22:15:16-08:00" level=warning msg="container 3695c6ba0cc961918bd3e4a769c52bd08b82afea5cd79e9749e9c7a63b5e7100: precreate hook: executing [sh -c echo 'oh, noes!' >&2; exit 1]: exit status 1" time="2018-12-02T22:15:16-08:00" level=error msg="error setting up OCI Hooks: executing [sh -c echo 'oh, noes!' >&2; exit 1]: exit status 1" Signed-off-by: W. Trevor King <wking@tremily.us>
* pkg/hooks/exec: Add a new package for local hook executionW. Trevor King2018-05-31
This wraps os/exec to: * Clear the environment when the hook doesn't set 'env'. The runtime spec has [1]: > * env (array of strings, OPTIONAL) with the same semantics as IEEE > Std 1003.1-2008's environ. And running execle or similar with NULL env results in an empty environment: $ cat test.c #include <unistd.h> int main() { return execle("/usr/bin/env", "env", NULL, NULL); } $ cc -o test test.c $ ./test ...no output... Go's Cmd.Env, on the other hand, has [2]: > If Env is nil, the new process uses the current process's environment. This commit works around that by setting []string{} in those cases to avoid leaking the runtime environment into the hooks. * Roll the 'timeout' value (if set) into the passed context. There's no need for two separate ways to cancel hook execution. * Add a configurable timeout on abandoning a post-kill wait. The waiting goroutine will continue and eventually reap the process, but this avoids blocking the Run() call when that takes inordinately long (for example, if a GPU cleanup hook is stuck in I/O sleep [3]). The 'env' output format is specified in POSIX [4]. [1]: https://github.com/opencontainers/runtime-spec/blob/v1.0.1/config.md#posix-platform-hooks [2]: https://golang.org/pkg/os/exec/#Cmd [3]: https://github.com/projectatomic/libpod/pull/857#discussion_r192191002 [4]: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/env.html Signed-off-by: W. Trevor King <wking@tremily.us> Closes: #857 Approved by: mheon