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] <javascript:>> 
> 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] <javascript:>.
> To post to this group, send email to [email protected] <javascript:>
> .
> 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.

Reply via email to