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

mules and signals #643

Closed
prymitive opened this Issue Jun 1, 2014 · 4 comments

Comments

Projects
None yet
3 participants
@prymitive
Contributor

prymitive commented Jun 1, 2014

2.0.5 introduced graceful reload for mules but I'm unable to intercept any signal in mule code, it works if I run it without uWSGI (python x.py). Is it uWSGI interfering with mule signals?

Test case below, touching /tmp/reload.txt or sending SIGHUP directly to my mule doesn't do anything.

x.py

import os
import signal
from time import sleep

def hand(*args, **kwargs):
    print(('EXITING', args, kwargs))

for sig in [signal.SIGTERM, signal.SIGINT, signal.SIGHUP,
            signal.SIGQUIT]:
    signal.signal(sig, hand)

while True:
    print(('ALIVE', os.getpid()))
    sleep(1)
# /usr/bin/uwsgi --plugins-dir /usr/lib/uwsgi/plugins --plugin python27 -M -s /tmp/mule.socket --mule=/tmp/x.py --touch-reload=/tmp/reload.txt
*** Starting uWSGI 2.0.5-upaas (64bit) on [Sun Jun  1 19:43:58 2014] ***
[...]
spawned uWSGI mule 1 (pid: 4619)
unable to stat() /tmp/reload.txt, events will be triggered as soon as the file is created
('ALIVE', 4619)
('ALIVE', 4619)
('ALIVE', 4619)
('ALIVE', 4619)
('ALIVE', 4619)
('ALIVE', 4619)
('ALIVE', 4619)
('ALIVE', 4619)
Sun Jun  1 19:44:06 2014 - *** /tmp/reload.txt has been touched... grace them all !!! ***
...gracefully killing workers...
Gracefully killing worker 1 (pid: 4618)...
('ALIVE', 4619)
worker 1 buried after 1 seconds
('ALIVE', 4619)
('ALIVE', 4619)
('ALIVE', 4619)
('ALIVE', 4619)
('ALIVE', 4619)
^C('ALIVE', 4619)
SIGINT/SIGQUIT received...killing workers...
goodbye to uWSGI.
('ALIVE', 4619)
@unbit

This comment has been minimized.

Owner

unbit commented Jun 2, 2014

try adding --py-call-osafterfork, it has been added to allow this patch working in every scenario. Very probably in > 2.0.x it will be enabled by default

@prymitive prymitive closed this Jun 2, 2014

@prymitive

This comment has been minimized.

Contributor

prymitive commented Jun 2, 2014

thanks

@tspike

This comment has been minimized.

tspike commented Apr 16, 2015

@unbit I'm running into a similar problem, we need to do some cleanup on mule exit. I confirm that --py-call-osafterfork allows this test case to work, but I'm nervous to use it based on your reply to another issue:

you cannot (by default) sanely override signals in uWSGI (unless you specify --py-call-osafterfork but this will break lot of internal behaviours)

What exactly are the implications of this option?

The 2.0.5 release notes say:

SIGHUP is now sent to mules instead of directly killing them. You are free to trap/catch the signal in your code. If a mule does not die in the allowed “mercy time” (–mule-reload-mercy, default 60 seconds), SIGKILL will be sent.

What will cause SIGHUP to be sent to the mule?

Thanks for all your work on uwsgi.

@unbit

This comment has been minimized.

Owner

unbit commented Apr 16, 2015

Just pay attention to override signals only in the mule and you should be safe

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment