Further update. I set stack-size in WSGIDaemonProcess *and* stack.size in wsgi.py
It appears that everything has stabilized. On Sunday, November 30, 2014 5:47:43 AM UTC-5, Steve M wrote: > > Update. > > apt-cache search is no longer throwing a segmentation fault. > > I would say that link you provided regarding ThreadStackSize was helpful > in helping me move forward. > > It appears that the problem was stemming from thread stack and how my > memory my VPS sees fit to allow access to. > > Steve > > > On Sunday, November 30, 2014 5:34:26 AM UTC-5, Steve M wrote: >> >> This is ubunut 10.04, an ancient version that the VPS company seems to be >> intent on keeping me on. >> >> Funny thing, I set: >> ThreadStackSize 524288 >> >> In mpm_worker_module and rebooted the VPS. >> >> Apache comes up on its own and acts normally, I dont have to restart >> apache to make mod_wsgi and apache behave now. >> >> When I run: >> sudo -u www-data ulimit -a >> I get: >> sudo: ulimit: command not found. >> >> There is no apache/Apache user. >> >> When I run it as su, I get: >> core file size (blocks, -c) 0 >> data seg size (kbytes, -d) unlimited >> scheduling priority (-e) 20 >> file size (blocks, -f) unlimited >> pending signals (-i) 16382 >> max locked memory (kbytes, -l) 64 >> max memory size (kbytes, -m) unlimited >> open files (-n) 1024 >> pipe size (512 bytes, -p) 8 >> POSIX message queues (bytes, -q) 819200 >> real-time priority (-r) 0 >> stack size (kbytes, -s) 8192 >> cpu time (seconds, -t) unlimited >> max user processes (-u) unlimited >> virtual memory (kbytes, -v) unlimited >> file locks (-x) unlimited >> >> >> When I run it as a regular user, I get: >> core file size (blocks, -c) 0 >> data seg size (kbytes, -d) unlimited >> scheduling priority (-e) 20 >> file size (blocks, -f) unlimited >> pending signals (-i) 16382 >> max locked memory (kbytes, -l) 64 >> max memory size (kbytes, -m) unlimited >> open files (-n) 1024 >> pipe size (512 bytes, -p) 8 >> POSIX message queues (bytes, -q) 819200 >> real-time priority (-r) 0 >> stack size (kbytes, -s) 8192 >> cpu time (seconds, -t) unlimited >> max user processes (-u) unlimited >> virtual memory (kbytes, -v) unlimited >> file locks (-x) unlimited >> >> >> When I set processes=2 in WSGIDaemonProcesses and restart apache the >> threads come up and apache and mod_wsgi appear to be running fine. >> But when I access a page I get an Internal Server Error. >> Nonetheless now after having set ThreadStackSize the errors are >> consistent and it doesnt look like apache or mod_wsgi are having trouble >> stabilizing the workers. >> >> The errors now are coming straight from python with the last line reading: >> ImproperlyConfigured: Error importing module >> django.contrib.auth.middleware: "cannot import name signals" >> >> So at this stage it seems the errors are coming from Python. >> >> I still am getting that stupid segmentation fault from apt-cache search, >> but I'm not going to worry about that for now. >> At this point I am more interested in seeing how to get this to work >> because I am probably going to move over to >> a different VPS. Therefore I want to have some knowledge base to take >> with me. >> >> >> >> On Sunday, November 30, 2014 5:14:38 AM UTC-5, Graham Dumpleton wrote: >>> >>> What do you get for 'ulimit -a' when run from a normal login shell? >>> >>> What do you get if you run it as: >>> >>> sudo -u www-data ulimit -a >>> >>> Replace 'www-data' with the Apache user if for some reason it is >>> different on your system. >>> >>> What specific release of Ubuntu is this? >>> >>> Graham >>> >>> On 30/11/2014, at 9:09 PM, Steve M <[email protected]> wrote: >>> >>> Checked the main error.log file and nothing relevant, just some: >>> Zlib: Compressed output indicating I had accessed the page. >>> >>> >>> But it is interesting that the topic of process limits comes up. >>> >>> When I reboot the VPS and apache tries to come up automatically I get >>> that: >>> [alert] (11)Resource temporarily unavailable: mod_wsgi (pid=1287): >>> Couldn't create worker thread 9 in daemon process 'server_site_a'. >>> >>> As if processes = 2 >>> Until I restart apache and it starts to behave. >>> >>> But the apache process count never seems to go above 5 no matter how >>> many different settings I change. >>> >>> >>> On Sunday, November 30, 2014 4:58:55 AM UTC-5, Graham Dumpleton wrote: >>>> >>>> >>>> On 30/11/2014, at 8:40 PM, Steve M <[email protected]> wrote: >>>> >>>> Hi Graham. >>>> >>>> Ok, so I basically put: >>>> import sys, os >>>> os.system('ulimit -a') >>>> >>>> at the top of the wsgi.py file >>>> >>>> Then later in def application I put: >>>> uval = os.system('ulimit -a') >>>> >>>> output = ' ' >>>> output += 'os.system = %s\n' % repr(uval) >>>> >>>> etc etc >>>> >>>> return [output] >>>> ----- >>>> >>>> The only relevant information I got was on the page which said: >>>> os.system = -1 >>>> >>>> But nothing relevant in error.log file near as I can tell. >>>> >>>> >>>> The os.system call only returns the exit status and not the output. >>>> >>>> The output would have been in the main Apache error log (not virtual >>>> host). >>>> >>>> That you were getting -1 though suggests that ulimit couldn't even be >>>> run because of hitting the process limit. >>>> >>>> Not that I know it to cause issues with starting processes, but some >>>> VPS systems have stupid memory allowances in place. >>>> >>>> Have a read of: >>>> >>>> >>>> http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Memory_Constrained_VPS_Systems >>>> >>>> The question though is whether after rebooting the system the issue >>>> occurred straight away? Did you find a large number of processes running? >>>> >>>> Graham >>>> >>>> Steve >>>> >>>> On Sunday, November 30, 2014 4:12:05 AM UTC-5, Graham Dumpleton wrote: >>>>> >>>>> >>>>> On 30/11/2014, at 5:59 PM, Steve M <[email protected]> wrote: >>>>> >>>>> > Hello, the problem I am having is that mod_wsgi fails if I set >>>>> process to anything greater than 1 in the WSGIDaemonProcess process=1 >>>>> > >>>>> > This is my current setup: >>>>> > [notice] Apache/2.2.14 (Ubuntu) mod_wsgi/4.4.1 Python/2.7.6 >>>>> configured -- resuming normal operations >>>>> > >>>>> > I compiled mod_wsgi from source. >>>>> > >>>>> > This seems to be the key error, but I am guessing: >>>>> > [alert] (11)Resource temporarily unavailable: mod_wsgi (pid=1287): >>>>> Couldn't create worker thread 9 in daemon process 'server_site_a'. >>>>> > Several of those pop up in the error log. >>>>> > >>>>> > WSGI settings in virtualhost: >>>>> > WSGIDaemonProcess server_site_a processes=1 threads=10 >>>>> display-name=%{GROUP} >>>>> > WSGIProcessGroup server_site_a >>>>> > WSGIApplicationGroup %{GLOBAL} >>>>> > >>>>> > >>>>> > In main apache2.conf: >>>>> > WSGIRestrictedEmbedded On >>>>> > >>>>> > And mpm_worker_module settings: >>>>> > >>>>> > StartServers 10 >>>>> > MaxClients 15 >>>>> > MaxRequestsPerChild 256 >>>>> > >>>>> > MinSpareThreads 10 >>>>> > MaxSpareThreads 20 >>>>> > ThreadsPerChild 15 >>>>> > ServerLimit 80 >>>>> > >>>>> > MaxMemFree 512 >>>>> > >>>>> > >>>>> > After watching Grahams videos on making apache suck less for python >>>>> I took some of his advice >>>>> > and decided to start fiddling with the apache settings. >>>>> > I first started off by getting apache to come up without errors >>>>> using mpm_worker. >>>>> > Once I had a baseline for apache I started to fiddle with mod_wsgi. >>>>> > So that is how I arrived at the settings. >>>>> > >>>>> > Would appreciate any help. >>>>> >>>>> >>>>> Manual page entry for pthread_create() says: >>>>> >>>>> ERRORS >>>>> pthread_create() will fail if: >>>>> >>>>> [EAGAIN] The system lacked the necessary resources to >>>>> create >>>>> another thread, or the system-imposed limit on >>>>> the >>>>> total number of threads in a process >>>>> [PTHREAD_THREADS_MAX] would be exceeded. >>>>> >>>>> This would therefore tend to indicate it is an issue with the limits >>>>> on the user Apache ends up running as, or the system as a whole. >>>>> >>>>> Can you start by putting back to a working configuration and then in a >>>>> WSGI hello world add: >>>>> >>>>> import os >>>>> os.system('ulimit -a') >>>>> >>>>> and hit the URL for the hello world script. >>>>> >>>>> Then get from the log file what that produces. >>>>> >>>>> BTW, appreciate that you are at least trying to make changes as many >>>>> these days just give and stop using mod_wsgi. :-( >>>>> >>>>> If we can sort out what the restriction is, I'll point out a few >>>>> things which still need fixing in what you quote. >>>>> >>>>> Graham >>>>> >>>>> >>>> -- >>>> 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. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>>> >>>> >>> -- >>> 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. >>> For more options, visit https://groups.google.com/d/optout. >>> >>> >>> -- 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. For more options, visit https://groups.google.com/d/optout.
