Linux nostromo 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:24 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux uWSGI 1.0-dev (uwsgi-1.0-rc7) Python 2.7.1+ (r271:86832, Apr 11 2011, 18:13:53)
I think master sends USR2, worker interrupts first sleep in def.. then continues to seconds sleep and after 1 sec of sleep master sends kill(uwsgi.workers[i].pid, SIGUSR2); which will lead in killing worker holding lock and thus no other request will proceed. 2012/2/1 Roberto De Ioris <[email protected]>: > >> I am sorry but uwsgi.lock() can deadlock. Here is an example: >> >> #!/usr/local/bin/python2.7 >> >> import uwsgi >> import os >> import time >> import random >> >> >> def do_lock_thing(): >> print "pid: %s going to lock" % os.getpid() >> uwsgi.lock() >> print "pid: %s locked." % os.getpid() >> sleep_time = 8 >> print "pid: %s going to sleep: %0.2f" % (os.getpid(), sleep_time) >> time.sleep(sleep_time) >> print "pid: %s going again to sleep: %0.2f" % (os.getpid(), >> sleep_time) >> time.sleep(sleep_time) >> print "pid: %s going to UNlock" % os.getpid() >> uwsgi.unlock() >> >> def application(environ, start_response): >> headers = [ >> ('Content-Type', 'text/html'), >> ] >> write = start_response('200 OK', headers) >> print "pid: %s request started" % os.getpid() >> time.sleep(5) >> for x in range(2): >> do_lock_thing() >> yield 'Hello World' >> print "pid: %s end of application.." % os.getpid() >> >> run as >> sudo uwsgi -s /var/run/uwsgi_hypernova.sock -M -p 2 --harakiri 10 >> --harakiri-verbose --pythonpath . -w uwsgi_test4_lock_in_def -C 777 >> >> The first process locks lock and then after it get kharakiri killed >> any other request will be blocked in uwsgi.lock() forever. >> >> pid: 7969 request started >> pid: 7970 request started >> pid: 7969 going to lock >> pid: 7969 locked. >> pid: 7969 going to sleep: 8.00 >> pid: 7970 going to lock >> *** HARAKIRI ON WORKER 1 (pid: 7969) *** >> HARAKIRI: -- syscall> 23 0x0 0x0 0x0 0x0 0x7fff5b298a00 0x1ffff >> 0x7fff5b298770 0x7f3ed5d08123 >> HARAKIRI: -- wchan> poll_schedule_timeout >> HARAKIRI: --- uWSGI worker 1 (pid: 7969) WAS managing request >> /serp?query=%D0%BF%D1%83%D1%82%D0%B8%D0%BD since Wed Feb 1 13:31:45 >> 2012 --- >> pid: 7969 going again to sleep: 8.00 >> *** HARAKIRI ON WORKER 2 (pid: 7970) *** >> HARAKIRI: -- syscall> 202 0x7f3ed799c0a0 0x0 0x2 0x0 0x7f3ed799c0a0 >> 0x1f22 0x7fff5b298a00 0x7f3ed756f7c4 >> HARAKIRI: -- wchan> futex_wait_queue_me >> HARAKIRI: --- uWSGI worker 2 (pid: 7970) WAS managing request >> /serp?query=%D0%BF%D1%83%D1%82%D0%B8%D0%BD since Wed Feb 1 13:31:46 >> 2012 --- >> DAMN ! worker 1 (pid: 7969) died :( trying respawn ... >> Respawned uWSGI worker 1 (new pid: 7971) >> DAMN ! worker 2 (pid: 7970) died :( trying respawn ... >> Respawned uWSGI worker 2 (new pid: 7972) >> pid: 7971 request started >> pid: 7971 going to lock >> *** HARAKIRI ON WORKER 1 (pid: 7971) *** >> HARAKIRI: -- syscall> 202 0x7f3ed799c0a0 0x0 0x2 0x0 0x7f3ed799c0a0 >> 0x1f23 0x7fff5b298a00 0x7f3ed756f7c4 >> HARAKIRI: -- wchan> futex_wait_queue_me >> HARAKIRI: --- uWSGI worker 1 (pid: 7971) WAS managing request >> /serp?query=%D0%BF%D1%83%D1%82%D0%B8%D0%BD since Wed Feb 1 13:32:08 >> 2012 --- >> pid: 7972 request started >> DAMN ! worker 1 (pid: 7971) died :( trying respawn ... >> Respawned uWSGI worker 1 (new pid: 7974) >> pid: 7972 going to lock >> ^CSIGINT/SIGQUIT received...killing workers... >> goodbye to uWSGI. >> >> >> > > This is a bug in uwsgi.lock()/unlock(), which kernel version ? > The usage of futex syscall means you are correctly running on > pthread_mutex, so it is a uWSGI problem for sure. > > I cannot reproduce it on linux 3.0 > > > -- > Roberto De Ioris > http://unbit.it > _______________________________________________ > uWSGI mailing list > [email protected] > http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi -- -------------------------------------------- Турнаев Евгений Викторович +7 906 875 09 43 -------------------------------------------- _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
