This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] sunrpc: Properly cleanup if tst-udp-timeout fails
- From: Florian Weimer <fw at deneb dot enyo dot de>
- To: Matheus Castanho <msc at linux dot ibm dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Fri, 07 Feb 2020 21:31:53 +0100
- Subject: Re: [RFC] sunrpc: Properly cleanup if tst-udp-timeout fails
- References: <20200205210517.21850-1-msc@linux.ibm.com>
* Matheus Castanho:
> I recently noted some orphan processes left on a host after failed
> sunrpc/tst-udp-timeout.c runs. More info on the commit message.
>
> Even though the test infra has support for a cleanup_function, it
> is only called when the test times out. The same happens for the code
> to kill the whole process group (both on the signal handler in
> support/support_test_main.c). So I ended up adding a cleanup function
> to be called right before exit() to terminate the child.
>
> I also considered using a function with __attribute__((destructor))
> to perform the cleanup, but adding a new TEST_VERIFY_* macro seemed
> to be more reusable by other tests if needed.
>
> Is this the best way to handle this issue?
I'm not sure. I think other processes have the same issue, and having
a generic solution would be nice.
We could perhaps add a fork wrapper that uses prctl with
PR_SET_PDEATHSIG, at least on Linux. It's not possible to transfer
the cleanup to the outmost monitor process because the test failure is
only noticed after waitpid returns, at which point the process group
no longer exists. Using a PID namespace would probably work better,
but it requires privileges (either root or at last user namespace
creation, as usual).
For the concrete patch, I think TEST_VERIFY_CLEANUP is confusing
because it does not perform the cleanup in both cases, and also the
exit function call is now obscured. It may be better to replace
TEST_VERIFY_EXIT with TEST_VERIFY. Or isolate the client in a
subprocess, too, so that the kill/waitpid sequence for the server
subprocess runs even if the client process failed (but that makes it
harder to debug the client code). Just installing an atexit handler
may also be an option and acceptable in this case.
Thanks,
Florian