Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

fix hang with ginkgo -p #1192

Merged
merged 4 commits into from
May 3, 2023
Merged

fix hang with ginkgo -p #1192

merged 4 commits into from
May 3, 2023

Commits on May 3, 2023

  1. integration: build interceptor binary automatically 

    Trying to run this locally the interceptor binary did not exists.
Lets just build this in SynchronizedBeforeSuite() automatically so
users do not have to figure this out.

Signed-off-by: Paul Holzinger <pholzing@redhat.com>
    @Luap99
    Luap99 committed May 3, 2023
    Configuration menu
    Copy the full SHA
    ffd0055 View commit details
    Browse the repository at this point in the history

  2. integration: make interceptor test parallel safe 

    Using the same file name for all test cause conflicts when run in
parallel, this causes the tests to fail for me. To fix this use a
filename suffix with GinkgoParallelProcess() which prevents conflicts
in the file name.

Signed-off-by: Paul Holzinger <pholzing@redhat.com>
    @Luap99
    Luap99 committed May 3, 2023
    Configuration menu
    Copy the full SHA
    d51a0a2 View commit details
    Browse the repository at this point in the history

  3. fix hang with ginkgo -p 

    When you run any child process that stay around longer than the test
suite ginkgo currently hangs. This is because the dup stdout/err fds are
leaked into the child thus read() will block on it as there is at least
one process still having the write pipe open.

From ginkgos POV it looks like it is done, you see the ginkgo result
output printed but then it just hangs and doe snot exit because of it.

To fix it we set FD_CLOEXEC on the dup-ed fds, this prevents them from
ever being leaking into other processes that could outlive the suite.
There is a dup3() call the could be uses to set the CLOEXEC option
directly but this seem linux only and thus is less portable.
The fcntl call should be good enough here, we do not need to be worried
about the race conditions described in the man page.
Ideally we should do some error handling in that function for both the
fcntl calls and the existing dup() above, however this seems like a
rather big change.

I am not so sure about how to test it properly, I added a test which
just executes `ginkgo run -p` and a test which only starts `sleep 60`.
Ginkgo then should exit right way and keep this process running. Then I
just make sure the gingo exits in under 15 seconds. As long as it is
below 60s it should fulfil the purpose.

Fixes onsi#1191

Signed-off-by: Paul Holzinger <pholzing@redhat.com>
    @Luap99
    Luap99 committed May 3, 2023
    Configuration menu
    Copy the full SHA
    a5c22da View commit details
    Browse the repository at this point in the history

  4. Rearrange new interceptor hang tests and confirm they cover the issue… 

    … in question
    @onsi
    onsi committed May 3, 2023
    Configuration menu
    Copy the full SHA
    037445a View commit details
    Browse the repository at this point in the history