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.

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 8 commits into from
Apr 11, 2024
Merged

Backports for 2.0.25 #2628

merged 8 commits into from
Apr 11, 2024

Conversation

xrmx
Copy link
Collaborator

@xrmx xrmx commented Apr 7, 2024

@niol @methane could you please give this branch a try? Thanks!

Lalufu and others added 8 commits April 7, 2024 14:13
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.
@xrmx xrmx changed the title Backport 2025 Backport 2.0.25 Apr 7, 2024
@xrmx xrmx changed the title Backport 2.0.25 Backports for 2.0.25 Apr 7, 2024
@methane
Copy link
Contributor

methane commented Apr 7, 2024

LGTM

@xrmx xrmx merged commit 8e7585e into unbit:uwsgi-2.0 Apr 11, 2024
31 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants