-
Notifications
You must be signed in to change notification settings - Fork 10.6k
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.
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
Post-fork hang after atfork handlers in glibc (Linux, Gevent) #38020
Comments
Hi @suntropez, thanks for reporting this. 1.56.0 looks like quite an old version, can you also try running with a recent version of gRPC and see if it helps. |
Just added two new tracebacks we got yesterday from a debug build.
Indeed. We have a pile of things on top, so currently updating (and reproducing in the original environment) would be a whole endeavor. AFAIK there was no luck reproducing with a very small project (just |
Some good news. Based on those traces, we tried disabling |
Hi @suntropez, thanks for the update. I am marking the issue as closed as you've managed to resolve it. Feel free to reopen if there are any further issues. |
I understand if closing it would be preferred in the end (given forking is known to be delicate and not really supported) but I wanna voice out that the workaround we found is just that. Applying the build flags to not support the forking can be intensely annoying depending on how complex the project is, given the so many gotchas of Python tooling and |
@eugeneo do we currently support setting these fork support flags at runtime or using environment variables? |
I am currently working on a fork support for future gRPC versions, starting from a clean slate. I am not familiar with the current implementation... |
What version of gRPC and what language are you using?
1.56.0 with gevent around 22.10.2-3
What operating system (Linux, Windows,...) and version?
Linux 6+
What runtime / compiler are you using (e.g. python version or version of gcc)
Python
3.9.*/3.11.*
from multiple sources (Debian upstream or non-special builds of vanilla CPython)What did you do?
Forked to subprocess.
Details
This is the meat of the stack frames, upwards from the
at fork
handlers.New tracebacks based on a debug build:
Child main thread
Child another thread
This happens around once every many thousand times. It seems to be timing sensitive, as reproduction ease varies across environments, as well as seemingly being sensitive to prints/logging added. At the hang point, a futex call, 7 or 8 threads have already been restarted (the grpc threadpool) and also hang together, so post-fork handlers did run, to some extent, on the child. Gevent 20+ is heavily used in the project. I don't have a really well isolated reproducer. We did not try very recent versions. The
GRPC_ENABLE_FORK
(or something like that) variable was experimented with at runtime to no avail. In this project we don't actually care about forking without soon exec'ing anyway. There's seemingly nothing wrong in the parent process.The reproduction context -- trying to not add uncertain things or misinformation in general - seems to be "fork a lot while having >1 thread running on the parent".
The text was updated successfully, but these errors were encountered: