What was the latest on this? I lost track due to inbox back log. Graham
On 30/11/2014, at 9:59 PM, Steve M <[email protected]> wrote: > 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. -- 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.
