Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

oci hooks: print stdout/err on error

Open
  • Is something wrong?
#2,358 2 comments 0 reactions 1 assignee View on GitHub

Maintainers usually reply within 1 day

@kolyshkin is already working on this.

Since Oct 21, 2026.

  • #2379 by @Rajkaran-122 — closed without merging

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
c, linux
Domain
backend, operating-systems

Research direction

Start by reading the OCI hook execution and error handling paths, then inspect how the run.oci.hooks.stdout/stderr annotations currently route output. Add bounded buffering when those annotations are absent and include the failed hook's stdout and stderr in its error. Done means a failing hook's output appears in the error, while existing annotation behavior remains understood and covered.

Written by the indexing model from the issue text.

Description

crun recently enhanced the hook error message https://github.com/containers/crun/commit/9db5c4f2a9592907a9419561f582a8d87d447ad6 to print which hook, however for an end user they still do not know why the hook failed as the sdterr/out is not printed as part of the error.

Compared to runc which does seem to print the output:

runc create failed: unable to start container process: error during container init: error running createRuntime hook #0: exit status 2, stdout: stdout
, stderr: stderr

when using a basic failure example hook like this

#!/bin/bash

echo stdout
echo stderr >&2

exit 2

crun offers the run.oci.hooks.stdout/stderr annotations which do not help that much as a user needs to know to set them and check them and they would always print the output not just for the failed hook. In case of multiple hooks that may be a problem as a user could not know which output was written by which hook.

As such I would suggest if no run.oci.hooks.stdout/stderr is given the output should be buffered and added to the error message. If we are worried about the unlimted size we could limit the buffer to something like 8K which I think would be reasonable for most cases.

If this is generally acceptable I am willing to work on this and propose a PR.

Dominant language
C
Stars
4.2k
Forks
459
Avg merge
23h 22m
Merged PRs (30d)
91

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from containers/crun

All issues in containers/crun

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.