Change:
What happened: Ran the conformance image via Sonobuoy with the E2E_DRYRUN option set. Results for the plugin were missing from the resulting tarball and the logs showed: What you expected to happen: No error, the plugin runs normally and reports results. How to reproduce it (as minimally and precisely as possible): Not 100%, but it has been reported and I've seen the tarball. It is just racy Check the logs to see if it includes . There may or may not be some results in but in the cases reported to me there was just a 0 length file for Anything else we need to know?: The problem just seems to be that the command gets the right PID but then the command is finished before starts. This causes the script to exit badly and not properly report its results.
/sig testing
Same error from my side using the command "sonobuoy run". Sonobuoy Version: v0.14.2
Just to be clear, you saw that error when doing a normal (which runs the whole conformance suite)? I'm the primary maintainer of Sonobuoy right now and that indeed seems odd if that's the case (since there would be no reason to have a race with the long-lived test run). If you wouldn't mind, I'd be very interested in seeing the results tarball from that run (you can find me in the k8s slack ( As I mentioned in the issue regarding generic flag options (linked above), one way to help solve/mitigate this would be to have the image use a different runner than bash (presumably Go) so that we could more clearly and elegantly handle the timing/errors/etc.
yes exactly, but when launching it again on the same cluster, I didn't have this error anymore. I'll send results to you on slack.
Yea you're error message is maybe even more confusing: It looks like couldn't find the running command. No indication that it failed, but it wasn't running hence the empty pid/valid job spec. Looking at yours also made me realize that my message given in the description actually listed 2 values (separated by newlines which is why I didnt notice it). So maybe pgrep was seeing the tee and the ginkgo command? So it wasn't that it terminated so fast, but that this approach of then just isn't very foolproof and has confusing error cases.
How would you feel about me creating an alternative to the ? I wouldn't remove it (so no risk of irrevocably breaking the image) but adding a go binary here too that could run the tests and might be easier to analyze error paths and such. Even handling args/flags more elegantly if we expand it.
go for it!
I am putting up the PR for the go runner, but fwiw I wanted to ping this ticket and mention that I have been getting this PID issue in Sonobuoy's CI system probably once a day.

Discussion:
) set -x <del> /usr/local/bin/ginkgo "${ginkgo_args[@]}" /usr/local/bin/e2e.test -- --disable-log-dump --repo-root=/kubernetes --provider="${E2E_PROVIDER}" --report-dir="${RESULTS_DIR}" --kubeconfig="${KUBECONFIG}" -v="${E2E_VERBOSITY}" | tee "${RESULTS_DIR}"/e2e.log & </del> <ins> /usr/local/bin/ginkgo "${ginkgo_args[@]}" /usr/local/bin/e2e.test -- --disable-log-dump --repo-root=/kubernetes --provider="${E2E_PROVIDER}" --report-dir="${RESULTS_DIR}" --kubeconfig="${KUBECONFIG}" -v="${E2E_VERBOSITY}" > >(tee "${RESULTS_DIR}"/e2e.log) ret=$? </ins> set +x <del> # $! is the pid of tee, not ginkgo wait "$(pgrep ginkgo)" && ret=0 || ret=$? </del> saveResults exit ${ret}