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.
