I just have to fiddle with the processes setting in WSGIDaemonProcesses otherwise I'll get a seg fault when trying to run apt-cache search. It seems a setting of 10 will throw that error, whereas 2 does not.
On Sunday, November 30, 2014 5:49:56 AM UTC-5, Steve M wrote: > > 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.
