-
Notifications
You must be signed in to change notification settings - Fork 691
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
Backports for 2.0.25 #2628
Merged
Merged
Backports for 2.0.25 #2628
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Starting with glusterfs 6.0, the IO callback function takes two additional parameters for stats structs. Ideally there'd be a way to detect which API version we're building against, but nothing convenient seems to exist.
I reviewed all options that mention `default` in their help string and found these two discrepancies.
Co-authored-by: loqs <loqs@users.noreply.github.com>
…rsion - You can now pass a different path for a different python installation.
- If this call fails, we need to release the gil before returning as we've obtained it.
worker stops when reached max_requests or reload_on_*. https://github.com/unbit/uwsgi/blob/39f3ade88c88693f643e70ecf6c36f9b375f00a2/core/utils.c#L1216-L1251 `goodbye_cruel_world()` is not graceful. It caused `atexit` not called. If atexit stops daemon threads, worker won't stop until killed from master. Using a reproducer similar to tests/threads_atexit.py: *** uWSGI is running in multiple interpreter mode *** spawned uWSGI master process (pid: 93920) spawned uWSGI worker 1 (pid: 93921, cores: 80) ...The work of process 93921 is done (max requests reached (641 >= 20)). Seeya! worker 1 killed successfully (pid: 93921) Respawned uWSGI worker 1 (new pid: 94019) ...The work of process 94019 is done (max requests reached (721 >= 20)). Seeya! worker 1 killed successfully (pid: 94019) Respawned uWSGI worker 1 (new pid: 94099) ...The work of process 94099 is done (max requests reached (721 >= 20)). Seeya! worker 1 killed successfully (pid: 94099) Respawned uWSGI worker 1 (new pid: 94179) ...The work of process 94179 is done (max requests reached (721 >= 20)). Seeya! worker 1 killed successfully (pid: 94179) Respawned uWSGI worker 1 (new pid: 94260) ...The work of process 94260 is done (max requests reached (721 >= 20)). Seeya! worker 1 killed successfully (pid: 94260) Respawned uWSGI worker 1 (new pid: 94340) atexit is not called. *** uWSGI is running in multiple interpreter mode *** spawned uWSGI master process (pid: 94781) spawned uWSGI worker 1 (pid: 94782, cores: 80) ...The work of process 94782 is done (max requests reached (402 >= 20)). Seeya! on_exit: uwsgi.worker_id()=1 worker 1 killed successfully (pid: 94782) Respawned uWSGI worker 1 (new pid: 94880) ...The work of process 94880 is done (max requests reached (721 >= 20)). Seeya! on_exit: uwsgi.worker_id()=1 worker 1 killed successfully (pid: 94880) Respawned uWSGI worker 1 (new pid: 94960) ...The work of process 94960 is done (max requests reached (721 >= 20)). Seeya! on_exit: uwsgi.worker_id()=1 worker 1 killed successfully (pid: 94960) Respawned uWSGI worker 1 (new pid: 95040) ...The work of process 95040 is done (max requests reached (721 >= 20)). Seeya! on_exit: uwsgi.worker_id()=1 worker 1 killed successfully (pid: 95040) Respawned uWSGI worker 1 (new pid: 95120) ...The work of process 95120 is done (max requests reached (721 >= 20)). Seeya! on_exit: uwsgi.worker_id()=1 worker 1 killed successfully (pid: 95120) Respawned uWSGI worker 1 (new pid: 95200) atexit is called Related issue: open-telemetry/opentelemetry-python#3640
When working to reproduce unbit#2615 I saw many strange "defunct" (zombie) workers. The master called waitpid(-1, ...) but it return 0 even there are some zombies. Finally, master sends KILL signal (MERCY) and worker is restarted. I believe this strange zombie was born from pthread_cancel. Subthreads calls pthread_cancel() for main thread and it cause strange process. pthread_cancel() is very hard to use and debug. I can not even attach the strange zombie with gdb --pid. I think it is not maintainable. In the end we can remove six_feet_under_lock and make wait_for_threads() static.
LGTM |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
@niol @methane could you please give this branch a try? Thanks!