Hum, actually updating to the latest revision in 3.5-dev healed the problem, both for 2.4.4 and 2.4.1
Apache 2.4.4 mod_wsgi 3.5-dev (starting from changeset bdbeacb88f34, "Scoreboard handle in daemon mode should be set to NULL for Apache 2.4 to avoid crash in lingering close.") Python 2.7.2 Daemon Mode works Ok without startup crashes! Chingis Le lundi 22 avril 2013 12:22:05 UTC+2, Chingis Dugarzhapov a écrit : > > Hello guys, > > Just to confirm that issue still persists in 2.4.4, as well as in 2.4.1... > (mod_wsgi 3.4/3.5) > > The issue is quite embarrassing. Segfaults force reinitialization of all > mod_wsgi python environment which cause several seconds timeouts during > first requests. We are obliged to run a backup server during deployment in > production in order to make segfaults "pass though" with dummy shooters. > > Graham, could you kindly provide some visibility on when the issue would > be fixed? (we cannot go back 2.2 :( and of course Embedded mode is *not* a > solution for us) > > Cheers, > > -- > Chingis > > > Le jeudi 28 mars 2013 06:18:09 UTC+1, Graham Dumpleton a écrit : >> >> There has been one other report of this with Apache 2.4.2. >> >> https://groups.google.com/d/topic/modwsgi/ehiiqqjQ6aA/discussion >> >> I didn't really have the time to look at it properly back then, but the >> code has always worked before with no issue and Apache wouldn't have change >> how memory pools are managed when reading configuration. I would be >> surprised if have managed to have a latent bug in there for so long. >> >> Any chance you can try Apache 2.4.4 and see if the issue goes away. >> >> Graham >> >> >> On 28 March 2013 04:18, Don Tillman <[email protected]> wrote: >> >>> Hi, >>> >>> With mod_wsgi 3.4, apache httpd 2.4.2, apr 1.4.6, apr_util 1.4.1. >>> >>> Embedded Mode seems to work well. But I need Daemon Mode. >>> >>> When I add the WSGIProcessGroup directive to the config file and restart >>> Apache httpd, it blows out immediately with a segmentation fault with no >>> mention in the log. >>> >>> It happens in mod_wsgi.c, on line 10069, this: >>> >>> entry->server = cmd->server; >>> >>> >>> Debugging: >>> >>> -------- >>> gdb /usr/sbin/httpd >>> b wsgi_add_daemon_process >>> run -X -f /etc/opt/tms/output/httpd.conf >>> -------- >>> >>> >>> The first call to wsgi_add_daemon_process goes without incident. It's >>> the second call that's a problem. >>> >>> -------- >>> Breakpoint 1, wsgi_add_daemon_process (cmd=0x7fffffffdb30, >>> mconfig=0x8cd0b0, args=0x8d08b8 "djangodaemon threads=15") at >>> mod_wsgi.c:9720 >>> 9720 mod_wsgi.c: No such file or directory. >>> in mod_wsgi.c >>> -------- >>> >>> Go to the line, examine the locals: >>> >>> -------- >>> (gdb) until 10069 >>> wsgi_add_daemon_process (cmd=0x7fffffffdb30, mconfig=0x8cd0b0, >>> args=0x8d08cf "") at mod_wsgi.c:10069 >>> 10069 in mod_wsgi.c >>> (gdb) p *wsgi_daemon_list >>> $1 = {pool = 0x80d138, elt_size = 280, nelts = 1, nalloc = 20, elts = >>> 0x944058 ""} >>> (gdb) p *cmd->server >>> $2 = {process = 0x80b218, next = 0x0, error_fname = 0x5890ce >>> "logs/error_log", error_log = 0x8809f8, log = {module_levels = 0x0, level = >>> 4}, module_config = 0x8c77c8, >>> lookup_defaults = 0x8cbd78, defn_name = 0x0, defn_line_number = 0, >>> is_virtual = 0 '\000', port = 0, server_scheme = 0x0, server_admin = >>> 0x5890bb "[no address given]", >>> server_hostname = 0x0, addrs = 0x880a70, timeout = 60000000, >>> keep_alive_timeout = 5000000, keep_alive_max = 100, keep_alive = 1, names = >>> 0x0, wild_names = 0x0, >>> path = 0x0, pathlen = 0, limit_req_line = 8190, limit_req_fieldsize = >>> 8190, limit_req_fields = 100, context = 0x0} >>> (gdb) p entry >>> $3 = (WSGIProcessGroup *) 0x944058 >>> -------- >>> >>> Okay. Continue, for the next call. >>> >>> -------- >>> (gdb) c >>> Continuing. >>> Missing separate debuginfo for /lib64/libnss_files.so.2 >>> Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install >>> /var/lib/debug/.build-id/19/c24fb834453511d12dfb4283d3c70f1346e974.debug >>> >>> Breakpoint 1, wsgi_add_daemon_process (cmd=0x7fffffffdb30, >>> mconfig=0x852730, args=0x8d14a0 "djangodaemon threads=15") at >>> mod_wsgi.c:9720 >>> 9720 in mod_wsgi.c >>> -------- >>> >>> Go to the line, examine the locals. >>> >>> -------- >>> (gdb) until 10069 >>> wsgi_add_daemon_process (cmd=0x7fffffffdb30, mconfig=0x852730, >>> args=0x8d14b7 "") at mod_wsgi.c:10069 >>> 10069 in mod_wsgi.c >>> (gdb) p *wsgi_daemon_list >>> $4 = {pool = 0x5929f0, elt_size = 10, nelts = 1, nalloc = 4567695, elts >>> = 0x592b78 "mod_file_cache.c"} >>> (gdb) p *cmd->server >>> $5 = {process = 0x80b218, next = 0x0, error_fname = 0x5890ce >>> "logs/error_log", error_log = 0x845cb8, log = {module_levels = 0x0, level = >>> 4}, module_config = 0x845ee0, >>> lookup_defaults = 0x8513f8, defn_name = 0x0, defn_line_number = 0, >>> is_virtual = 0 '\000', port = 0, server_scheme = 0x0, server_admin = >>> 0x5890bb "[no address given]", >>> server_hostname = 0x0, addrs = 0x845d30, timeout = 60000000, >>> keep_alive_timeout = 5000000, keep_alive_max = 100, keep_alive = 1, names = >>> 0x0, wild_names = 0x0, >>> path = 0x0, pathlen = 0, limit_req_line = 8190, limit_req_fieldsize = >>> 8190, limit_req_fields = 100, context = 0x0} >>> (gdb) p entry >>> $6 = (WSGIProcessGroup *) 0x592b78 >>> -------- >>> >>> Continue, and blammo... >>> >>> -------- >>> (gdb) c >>> Continuing. >>> >>> Program received signal SIGSEGV, Segmentation fault. >>> 0x00000000004fcdd6 in wsgi_add_daemon_process (cmd=0x7fffffffdb30, >>> mconfig=0x852730, args=0x8d14b7 "") at mod_wsgi.c:10069 >>> 10069 in mod_wsgi.c >>> (gdb) >>> -------- >>> >>> So it's not the usual kind of null pointer segv situation. The >>> assignment on line 10069 looks to me like it should work. >>> >>> I did notice that wsgi_daemon_lists's nalloc value looks mighty large >>> the second time around; perhaps that's an issue. >>> >>> Any ideas? This is very frustrating. >>> >>> -- Don >>> >>> >>> >>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "modwsgi" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at http://groups.google.com/group/modwsgi?hl=en. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> >>> >> >> -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/modwsgi?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
