Dear Graham, Same error after removing the trailing slash. The socket files 
get created anyways in /run/httpd/wsgi.21949.0.1.sock

I believe we are just one step away from solving this but I am a bit lost.

On Wednesday, 18 March 2020 23:35:22 UTC-3, Graham Dumpleton wrote:
>
>
>
> On 19 Mar 2020, at 1:34 pm, Graham Dumpleton <[email protected] 
> <javascript:>> wrote:
>
> Get rid the trailing slash on:
>
> WSGISocketPrefix /run/httpd/wsgi/
>
> it should be:
>
> WSGISocketPrefix /run/httpd/wsgi/
>
>
> Whoops.
>
> WSGISocketPrefix /run/httpd/wsgi
>
> Remove the directory:
>
> /run/httpd/wsgi
>     
> What are the permissions on the directory '/run/httpd'. Ie.,
>
> ls -lasd /run/httpd
>
> There is no reason to change User/Group directives for Apache as a whole.
>
> Graham
>
> On 19 Mar 2020, at 1:22 pm, Guddu <[email protected] <javascript:>> 
> wrote:
>
> Dear Graham, after taking QA out and accessing it it did not work. 
>
> So I started the whole server just to see if that helps but strangely I am 
> back to the original error. 
>
> Here is the message in the apache logs upon accessing both the apps in 
> turn one after the other
>
> [Wed Mar 18 21:17:00.043635 2020] [wsgi:error] [pid 19948] (13)Permission 
> denied: [client 10.52.7.170:1251] mod_wsgi (pid=19948): Unable to connect 
> to WSGI daemon process 'app_qa' on '/run/httpd/wsgi/.19945.0.1.sock' as 
> user with uid=1001.[Wed Mar 18 21:18:21.667963 2020] [wsgi:error] [pid 
> 19949] (13)Permission denied: [client 10.52.7.170:1254] mod_wsgi (pid=
> 19949): Unable to connect to WSGI daemon process 'app_prod' on 
> '/run/httpd/wsgi/.19945.0.2.sock' as user with uid=1001.
>
>
>
>
> That uid of 1001 corresponds to the same user with which i am runing the 
> apache and specified in User and Groups directive.
> The permissions on those socket files are as follows
>
>
> [root@server app]# ls -ltra /run/httpd/wsgi/
> total 0
> srwx------ 1 app_user root      0 Mar 18 21:14 .19945.0.1.sock
> srwx------ 1 app_user root      0 Mar 18 21:14 .19945.0.2.sock
>
>
>
> On Wednesday, 18 March 2020 23:03:49 UTC-3, Graham Dumpleton wrote:
>>
>> But when you took the QA app out, the QA app definitely didn't work if 
>> you tried accessing it? Just trying to make sure that the QA config isn't 
>> being read from somewhere else.
>>
>> Also make sure you have no strange unicode characters in the URL path of 
>> WSGIScriptAlias. Type it in again from scratch.
>>
>> On 19 Mar 2020, at 1:01 pm, Guddu <[email protected]> wrote:
>>
>> Dear Graham, the wsgi.py file exists.
>>
>> [root@server app]# ls -ltr /opt/app/app_prod/app/wsgi.py
>> -rw-r--r-- 1 app_user app_user 411 Mar 18 06:53 /opt/app/app_prod/app/
>> wsgi.py
>>
>>
>>
>> There is no other entity using the port 8999
>>
>> [root@server app]# netstat -an | grep 8999
>> tcp6       0      0 :::8999                 :::*                   
>>  LISTEN
>> [root@server app]# service httpd stop
>> Redirecting to /bin/systemctl stop httpd.service
>> [root@server app]# netstat -an | grep 8999
>> [root@server app]#
>>
>>
>>
>> If i put in the QA wsgi app it works. Below is the config.
>>
>> WSGISocketPrefix /run/httpd/wsgi/
>> <VirtualHost *:8999>
>> WSGIDaemonProcess app_qa processes=1 display-name=%{GROUP} python-path=
>> /opt/app/app_qa/app
>> #WSGIProcessGroup app_qa
>> WSGIScriptAlias /app_qa /opt/app/app_qa/app/wsgi.py  process-group=app_qa 
>> application-group=%{GLOBAL}
>> Alias /static_app_qa /opt/app/app_qa/staticfiles
>>
>> <Directory /opt/app/app_qa/app/>
>>         <Files wsgi.py>
>>                 Require all granted
>>         </Files>
>> </Directory>
>>
>> <Directory /opt/app/app_qa/staticfiles/>
>>         Require all granted
>> </Directory>
>>
>> </VirtualHost>
>>
>>
>>
>>
>> If i put in the PROD wsgi app it does not works Below is the config.
>>
>> WSGISocketPrefix /run/httpd/wsgi/
>>
>> <VirtualHost *:8999>
>> WSGIDaemonProcess app_prod processes=1 display-name=%{GROUP} python-path=
>> /opt/app/app_prod/app
>> WSGIProcessGroup app_prod
>> WSGIScriptAlias /app_prod /opt/app/app_prod/app/wsgi.py  
>> process-group=app_prod 
>> application-group=%{GLOBAL}
>> Alias /static_app_prod /opt/app/app_prod/staticfiles
>>
>> <Directory /opt/app/app_prod/app/>
>>         <Files wsgi.py>
>>                 Require all granted
>>         </Files>
>> </Directory>
>>
>> <Directory /opt/app/app_prod/staticfiles/>
>>         Require all granted
>> </Directory>
>> </VirtualHost>
>>
>>
>> On Wednesday, 18 March 2020 22:51:56 UTC-3, Graham Dumpleton wrote:
>>>
>>> Did the QA URL still work after you removed it?
>>>
>>> You sure you aren't using a standalone WSGI server run from command line 
>>> on port 8999 as well, preventing Apache from using the port?
>>>
>>> Does the file '/opt/app/app_prod/app/wsgi.py' exist?
>>>
>>> On 19 Mar 2020, at 12:39 pm, Guddu <[email protected]> wrote:
>>>
>>> Dear Graham, adding an XXX and restarting failed as expected.
>>>
>>> There is no sites-available directory and no other VirtualHosts for the 
>>> same port or for *.
>>>
>>> I removed the QA Site config leaving only the PROD one and it gives the 
>>> same error which is weird. I have checked all paths and they are fine. 
>>> Kindly guide. This is the current minimal configuration that I have. It has 
>>> to be something sillly now which I can't seem to figure out.
>>>
>>> WSGISocketPrefix /run/httpd/wsgi/
>>>
>>> <VirtualHost *:8999>
>>> WSGIDaemonProcess app_prod processes=1 display-name=%{GROUP} python-path
>>> =/opt/app/app_prod/app
>>> WSGIProcessGroup app_prod
>>> WSGIScriptAlias /app_prod /opt/app/app_prod/app/wsgi.py  
>>> process-group=app_prod 
>>> application-group=%{GLOBAL}
>>> Alias /static_app_prod /opt/app/app_prod/staticfiles
>>>
>>> <Directory /opt/app/app_prod/app/>
>>>         <Files wsgi.py>
>>>                 Require all granted
>>>         </Files>
>>> </Directory>
>>>
>>> <Directory /opt/app/app_prod/staticfiles/>
>>>         Require all granted
>>> </Directory>
>>> </VirtualHost>
>>>
>>>
>>>
>>>
>>> On Wednesday, 18 March 2020 22:20:07 UTC-3, Graham Dumpleton wrote:
>>>>
>>>> Add a syntax error to the file. Using "XXX" on a line by itself is 
>>>> enough and restart Apache again. See if it fails to restart because of the 
>>>> error. This will check whether the file is being read. If this is in a 
>>>> file 
>>>> in a sites-available directory, ensure that the site has been enabled and 
>>>> the sites-enabled directory contains a symlink to the file in the 
>>>> sites-available directory and is not a separate file copy. Also ensure you 
>>>> don't have a VirtualHost for the same port elsewhere in any config file, 
>>>> and that you don't have a VirtualHost which uses "*" for the port. Also 
>>>> try 
>>>> commenting out the config for the QA site and see if anything changes.
>>>>
>>>> So can only suggest you double check everything.
>>>>
>>>> On 19 Mar 2020, at 12:15 pm, Guddu <[email protected]> wrote:
>>>>
>>>> Dear Graham. Yes. The restart went well. Here is the log
>>>>
>>>>
>>>> [root@server app]# ps -ef| grep http
>>>> root     15399     1  0 19:55 ?        00:00:00 /usr/sbin/httpd -
>>>> DFOREGROUND
>>>> app_user  15402 15399  0 19:55 ?        00:00:00 /usr/sbin/httpd -
>>>> DFOREGROUND
>>>> app_user  15403 15399  0 19:55 ?        00:00:00 /usr/sbin/httpd -
>>>> DFOREGROUND
>>>> app_user  15404 15399  0 19:55 ?        00:00:00 /usr/sbin/httpd -
>>>> DFOREGROUND
>>>> app_user  15405 15399  0 19:55 ?        00:00:00 /usr/sbin/httpd -
>>>> DFOREGROUND
>>>> app_user  15406 15399  0 19:55 ?        00:00:00 /usr/sbin/httpd -
>>>> DFOREGROUND
>>>> [root@server app]# date
>>>> Wed Mar 18 20:08:06 -05 2020
>>>> [root@server app]# service httpd restart
>>>> Redirecting to /bin/systemctl restart httpd.service
>>>> [root@server app]# ps -ef| grep http
>>>> root     16129     1  3 20:08 ?        00:00:00 /usr/sbin/httpd -
>>>> DFOREGROUND
>>>> app_user  16132 16129  1 20:08 ?        00:00:00 /usr/sbin/httpd -
>>>> DFOREGROUND
>>>> app_user  16133 16129  1 20:08 ?        00:00:00 /usr/sbin/httpd -
>>>> DFOREGROUND
>>>> app_user  16134 16129  1 20:08 ?        00:00:00 /usr/sbin/httpd -
>>>> DFOREGROUND
>>>> app_user  16135 16129  1 20:08 ?        00:00:00 /usr/sbin/httpd -
>>>> DFOREGROUND
>>>> app_user  16136 16129  1 20:08 ?        00:00:00 /usr/sbin/httpd -
>>>> DFOREGROUND
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Wednesday, 18 March 2020 22:00:30 UTC-3, Graham Dumpleton wrote:
>>>>>
>>>>> That config looks fine. Are you absolutely sure Apache was restarted 
>>>>> correctly? Check the Apache error logs to make sure there wasn't a config 
>>>>> error that prevent a restart to use the new config.
>>>>>
>>>>> On 19 Mar 2020, at 11:56 am, Guddu <[email protected]> wrote:
>>>>>
>>>>> Dear Graham, so i changed it to the following bringing them under one 
>>>>> single VirtualHost and added application-group=%{GLOBAL} to 
>>>>> WSGIScriptAlias 
>>>>> but the same situation persists. I can access only the first app not the 
>>>>> second one. Here is the .conf setting.
>>>>>
>>>>> <VirtualHost *:8999>
>>>>> WSGIDaemonProcess app_qa processes=1 display-name=%{GROUP} 
>>>>> python-path=/opt/app/app_qa/app
>>>>> WSGIProcessGroup app_qa
>>>>> WSGIScriptAlias /app_qa /opt/app/app_qa/app/wsgi.py 
>>>>>  process-group=app_qa application-group=%{GLOBAL}
>>>>> Alias /static_app_qa /opt/app/app_qa/staticfiles
>>>>>
>>>>>
>>>>> <Directory /opt/app/app_qa/app/>
>>>>>         <Files wsgi.py>
>>>>>                 Require all granted
>>>>>         </Files>
>>>>> </Directory>
>>>>>
>>>>>
>>>>> <Directory /opt/app/app_qa/staticfiles/>
>>>>>         Require all granted
>>>>> </Directory>
>>>>>
>>>>>
>>>>> WSGIDaemonProcess app_prod processes=1 display-name=%{GROUP} 
>>>>> python-path=/opt/app/app_prod/app
>>>>> WSGIProcessGroup app_prod
>>>>> WSGIScriptAlias /app_prod /opt/app/app_prod/app/wsgi.py 
>>>>>  process-group=app_prod application-group=%{GLOBAL}
>>>>> Alias /static_app_prod /opt/app/app_prod/staticfiles
>>>>>
>>>>>
>>>>> <Directory /opt/app/app_prod/app/>
>>>>>         <Files wsgi.py>
>>>>>                 Require all granted
>>>>>         </Files>
>>>>> </Directory>
>>>>>
>>>>>
>>>>> <Directory /opt/app/app_prod/staticfiles/>
>>>>>         Require all granted
>>>>> </Directory>
>>>>> </VirtualHost>
>>>>>
>>>>>
>>>>> Kindly guide.
>>>>>
>>>>> On Wednesday, 18 March 2020 21:46:35 UTC-3, Graham Dumpleton wrote:
>>>>>>
>>>>>> You can't have two VirtualHost definitions for the same port number 
>>>>>> unless they have ServerName set for each to a different hostname. Even 
>>>>>> then, you can't access them by IP and have them distinguished, you would 
>>>>>> need to use the respective hostnames.
>>>>>>
>>>>>> So if you are going to use an IP address only, have one VirtualHost 
>>>>>> only and use inside of that for mod_wsgi:
>>>>>>
>>>>>> WSGIDaemonProcess app_qa 
>>>>>> processes=1 display-name=%{GROUP} python-path=/opt/app/app_qa/app
>>>>>> WSGIScriptAlias /app_qa /opt/app/app_qa/app/wsgi.py 
>>>>>>  process-group=app_qa application-group=%{GLOBAL}
>>>>>>
>>>>>> WSGIDaemonProcess app_prod 
>>>>>> processes=1 display-name=%{GROUP} python-path=/opt/app/app_prod/app
>>>>>> WSGIScriptAlias /app_prod /opt/app/app_prod/app/wsgi.py 
>>>>>>  process-group=app_prod application-group=%{GLOBAL}
>>>>>>
>>>>>> Add your other stuff for Alias etc as well for each.
>>>>>>
>>>>>> On 19 Mar 2020, at 11:42 am, Guddu <[email protected]> wrote:
>>>>>>
>>>>>> Dear Graham, Thanks for your response.
>>>>>>
>>>>>> I removed socket-user=app_user and now I see a different behaviour. 
>>>>>> One of the app work while the other does not. Both are exactly identical 
>>>>>> one is meant for QA and other for PROD and the QA URL works while for 
>>>>>> the 
>>>>>> PROD URL it shows an error 
>>>>>>
>>>>>> *Not Found The requested URL /app_prod was not found on this server.*
>>>>>>
>>>>>> The   QA    URL is http://<ip>:8999/app_qa
>>>>>> The PROD URL is http://<ip>:8999/app_prod
>>>>>>
>>>>>> The initial reason why I had to move to daemon mode is to be able to 
>>>>>> set a python-path for both of them separately as WSGIPythonPath cannot 
>>>>>> be 
>>>>>> used inside <VirtualHost>
>>>>>>
>>>>>> This is my httpd.conf setting.
>>>>>>
>>>>>> WSGISocketPrefix /run/httpd/wsgi/
>>>>>> <VirtualHost *:8999>
>>>>>> WSGIDaemonProcess app_qa processes=1 display-name=%{GROUP} python-
>>>>>> path=/opt/app/app_qa/app
>>>>>> WSGIProcessGroup app_qa
>>>>>> WSGIScriptAlias /app_qa /opt/app/app_qa/app/wsgi.py  process-group=
>>>>>> app_qa
>>>>>> Alias /static_app_qa /opt/app/app_qa/staticfiles
>>>>>>
>>>>>> <Directory /opt/app/app_qa/app/>
>>>>>>         <Files wsgi.py>
>>>>>>                 Require all granted
>>>>>>         </Files>
>>>>>> </Directory>
>>>>>>
>>>>>> <Directory /opt/app/app_qa/staticfiles/>
>>>>>>         Require all granted
>>>>>> </Directory>
>>>>>> </VirtualHost>
>>>>>>
>>>>>> <VirtualHost *:8999>
>>>>>> WSGIDaemonProcess app_prod processes=1 display-name=%{GROUP} python-
>>>>>> path=/opt/app/app_prod/app
>>>>>> WSGIProcessGroup app_prod
>>>>>> WSGIScriptAlias /app_prod /opt/app/app_prod/app/wsgi.py  process-
>>>>>> group=app_prod
>>>>>> Alias /static_app_prod /opt/app/app_prod/staticfiles
>>>>>>
>>>>>> <Directory /opt/app/app_prod/app/>
>>>>>>         <Files wsgi.py>
>>>>>>                 Require all granted
>>>>>>         </Files>
>>>>>> </Directory>
>>>>>>
>>>>>> <Directory /opt/app/app_prod/staticfiles/>
>>>>>>         Require all granted
>>>>>> </Directory>
>>>>>> </VirtualHost>
>>>>>>
>>>>>> The netstat output is as follows indicating that the socket files 
>>>>>> were created in the desired folder. The permission on files and 
>>>>>> directories 
>>>>>> also follows
>>>>>>
>>>>>> [root@server app]# netstat -an | grep http
>>>>>> unix  2      [ ACC ]     STREAM     LISTENING     1107556  /run/httpd
>>>>>> /wsgi/.13750.0.1.sock
>>>>>> unix  2      [ ACC ]     STREAM     LISTENING     1107558  /run/httpd
>>>>>> /wsgi/.13750.0.2.sock
>>>>>>
>>>>>> [root@server app]# ls -ltr /run/httpd/wsgi/.13750.0.1.sock 
>>>>>> /run/httpd/wsgi/.13750.0.2.sock
>>>>>> srwx------ 1 app_user root 0 Mar 18 19:29 /run/httpd/wsgi/.13750.0.
>>>>>> 2.sock
>>>>>> srwx------ 1 app_user root 0 Mar 18 19:29 /run/httpd/wsgi/.13750.0.
>>>>>> 1.sock
>>>>>>
>>>>>> [root@server app]# ls -ltr /run/httpd/
>>>>>> total 8
>>>>>> drwx------ 2 apache  apache  40 Mar 10 13:50 htcacheclean
>>>>>> -rw-r--r-- 1 root    root     8 Mar 18 19:29 authdigest_shm.13750
>>>>>> -rw-r--r-- 1 root    root     6 Mar 18 19:29 httpd.pid
>>>>>> drwxr-xr-x 2 app_user app_user 80 Mar 18 19:29 wsgi
>>>>>>
>>>>>> [root@server app]# ls -ltr /run | tail -2
>>>>>> -rw-rw-r--  1 root     utmp     3072 Mar 18 19:11 utmp
>>>>>> drwx--x---  4 root     apache    120 Mar 18 19:29 httpd
>>>>>>
>>>>>>
>>>>>>
>>>>>> Also the ps -ef | grep httpd output is
>>>>>>
>>>>>>
>>>>>> root     13750     1  0 19:29 ?        00:00:00 /usr/sbin/httpd -
>>>>>> DFOREGROUND
>>>>>> app_user  13753 13750  0 19:29 ?        00:00:00 /usr/sbin/httpd -
>>>>>> DFOREGROUND
>>>>>> app_user  13754 13750  0 19:29 ?        00:00:00 /usr/sbin/httpd -
>>>>>> DFOREGROUND
>>>>>> app_user  13755 13750  0 19:29 ?        00:00:00 /usr/sbin/httpd -
>>>>>> DFOREGROUND
>>>>>> app_user  13756 13750  0 19:29 ?        00:00:00 /usr/sbin/httpd -
>>>>>> DFOREGROUND
>>>>>> app_user  13757 13750  0 19:29 ?        00:00:00 /usr/sbin/httpd -
>>>>>> DFOREGROUND
>>>>>>
>>>>>>
>>>>>> I am a bit confused as everything seems alright.
>>>>>>
>>>>>> Appreciate your help
>>>>>>
>>>>>>
>>>>>> On Wednesday, 18 March 2020 18:57:26 UTC-3, Graham Dumpleton wrote:
>>>>>>>
>>>>>>> Why are you setting 'socket-user'?
>>>>>>>
>>>>>>> That is only required when using Apache PrivilegesMode as SECURE, or 
>>>>>>> using certain Apache MPMs.
>>>>>>>
>>>>>>> What happens when you don't use that?
>>>>>>>
>>>>>>> I want to see the original error messages and permissions on both 
>>>>>>> the socket files, *and* the directory the sockets are in, before 
>>>>>>> changing any configuration from what one would normally use.
>>>>>>>
>>>>>>> Graham
>>>>>>>
>>>>>>> On 19 Mar 2020, at 2:10 am, Guddu <[email protected]> wrote:
>>>>>>>
>>>>>>> After configuring daemon mode, I started getting a 503 Server 
>>>>>>> Unavailable error.
>>>>>>>
>>>>>>> There are lot of posts on stackoverflow and a dedicate section in 
>>>>>>> the troubleshooting page at 
>>>>>>> https://modwsgi.readthedocs.io/en/develop/user-guides/frequently-asked-questions.html
>>>>>>>  and 
>>>>>>> https://modwsgi.readthedocs.io/en/develop/user-guides/configuration-issues.html
>>>>>>>  but none of the suggestions seem to be helping me at the moment. 
>>>>>>> Appreciate your guidance.
>>>>>>>
>>>>>>> The error logs have the following
>>>>>>>
>>>>>>> [Wed Mar 18 09:30:17.649428 2020] [wsgi:error] [pid 14044] (13)
>>>>>>> Permission denied: [client 10.52.7.18:2505] mod_wsgi (pid=14044): 
>>>>>>> Unable to connect to WSGI daemon process 'app_qa' on 
>>>>>>> '/run/httpd/wsgi/.14039.0.1.sock' as user with uid=1001.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The directory in question has read and write permission to 
>>>>>>> *app_user*
>>>>>>>
>>>>>>> The httpd processes start fine. Below is the ps output
>>>>>>>
>>>>>>> root     14197     1  0 09:30 ?        00:00:00 /usr/sbin/httpd -
>>>>>>> DFOREGROUND
>>>>>>> app_user  14202 14197  0 09:30 ?        00:00:00 /usr/sbin/httpd -
>>>>>>> DFOREGROUND
>>>>>>> app_user  14203 14197  0 09:30 ?        00:00:00 /usr/sbin/httpd -
>>>>>>> DFOREGROUND
>>>>>>> app_user  14204 14197  0 09:30 ?        00:00:00 /usr/sbin/httpd -
>>>>>>> DFOREGROUND
>>>>>>> app_user  14205 14197  0 09:30 ?        00:00:00 /usr/sbin/httpd -
>>>>>>> DFOREGROUND
>>>>>>> app_user  14206 14197  0 09:30 ?        00:00:00 /usr/sbin/httpd -
>>>>>>> DFOREGROUND
>>>>>>>
>>>>>>>
>>>>>>>   
>>>>>>> The socket flies get written
>>>>>>>   
>>>>>>> [root@server wsgi]# ls -ltra
>>>>>>> total 0
>>>>>>> srwx------ 1 app_user root      0 Mar 18 09:30 .14197.0.1.sock
>>>>>>> srwx------ 1 app_user root      0 Mar 18 09:30 .14197.0.2.sock
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> My apache build info is as follows
>>>>>>>
>>>>>>> [app_user@server app_qa]$ httpd -V
>>>>>>> AH00558: httpd: Could not reliably determine the server's fully 
>>>>>>> qualified domain name, using 10.21.2.136. Set the 'ServerName' 
>>>>>>> directive globally to suppress this message
>>>>>>> Server version: Apache/2.4.6 (Red Hat Enterprise Linux)
>>>>>>> Server built:   Jun  9 2019 13:01:04
>>>>>>> Server's Module Magic Number: 20120211:24
>>>>>>> Server loaded:  APR 1.4.8, APR-UTIL 1.5.2
>>>>>>> Compiled using: APR 1.4.8, APR-UTIL 1.5.2
>>>>>>> Architecture:   64-bit
>>>>>>> Server MPM:     prefork
>>>>>>>   threaded:     no
>>>>>>>     forked:     yes (variable process count)
>>>>>>> Server compiled with....
>>>>>>>  -D APR_HAS_SENDFILE
>>>>>>>  -D APR_HAS_MMAP
>>>>>>>  -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
>>>>>>>  -D APR_USE_SYSVSEM_SERIALIZE
>>>>>>>  -D APR_USE_PTHREAD_SERIALIZE
>>>>>>>  -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
>>>>>>>  -D APR_HAS_OTHER_CHILD
>>>>>>>  -D AP_HAVE_RELIABLE_PIPED_LOGS
>>>>>>>  -D DYNAMIC_MODULE_LIMIT=256
>>>>>>>  -D HTTPD_ROOT="/etc/httpd"
>>>>>>>  -D SUEXEC_BIN="/usr/sbin/suexec"
>>>>>>>  -D DEFAULT_PIDLOG="/run/httpd/httpd.pid"
>>>>>>>  -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
>>>>>>>  -D DEFAULT_ERRORLOG="logs/error_log"
>>>>>>>  -D AP_TYPES_CONFIG_FILE="conf/mime.types"
>>>>>>>  -D SERVER_CONFIG_FILE="conf/httpd.conf"
>>>>>>>
>>>>>>>  [app_user@server app_qa]$ httpd -l
>>>>>>> Compiled in modules:
>>>>>>>   core.c
>>>>>>>   mod_so.c
>>>>>>>   http_core.c
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> My httpd conf is as follows
>>>>>>>   
>>>>>>> WSGISocketPrefix /run/httpd/wsgi/
>>>>>>> <VirtualHost *:8999>
>>>>>>> WSGIDaemonProcess app_qa processes=2 display-name=%{GROUP} python-
>>>>>>> path=/opt/app/app_qa  socket-user=app_user
>>>>>>> WSGIProcessGroup app_qa
>>>>>>> WSGIScriptAlias /app_qa /opt/app/app_qa/app/wsgi.py  process-group=
>>>>>>> app_qa
>>>>>>> Alias /static_app_qa /opt/app/app_qa/staticfiles
>>>>>>>
>>>>>>> <Directory /opt/app/app_qa/app/>
>>>>>>>         <Files wsgi.py>
>>>>>>>                 Require all granted
>>>>>>>         </Files>
>>>>>>> </Directory>
>>>>>>>
>>>>>>> <Directory /opt/app/app_qa/staticfiles/>
>>>>>>>         Require all granted
>>>>>>> </Directory>
>>>>>>> </VirtualHost>
>>>>>>>
>>>>>>>
>>>>>>> Appreciate your help on this matter.
>>>>>>>
>>>>>>> -- 
>>>>>>> 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 view this discussion on the web visit 
>>>>>>> https://groups.google.com/d/msgid/modwsgi/82ab46fe-adc1-42fd-90ad-abaf05f58613%40googlegroups.com
>>>>>>>  
>>>>>>> <https://groups.google.com/d/msgid/modwsgi/82ab46fe-adc1-42fd-90ad-abaf05f58613%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>>> .
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> -- 
>>>>>> 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 view this discussion on the web visit 
>>>>>> https://groups.google.com/d/msgid/modwsgi/21647165-18ba-4f06-92d0-b224f06e8311%40googlegroups.com
>>>>>>  
>>>>>> <https://groups.google.com/d/msgid/modwsgi/21647165-18ba-4f06-92d0-b224f06e8311%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>> .
>>>>>>
>>>>>>
>>>>>>
>>>>> -- 
>>>>> 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 view this discussion on the web visit 
>>>>> https://groups.google.com/d/msgid/modwsgi/d79bd082-9468-4a1c-bf86-8e377718ef48%40googlegroups.com
>>>>>  
>>>>> <https://groups.google.com/d/msgid/modwsgi/d79bd082-9468-4a1c-bf86-8e377718ef48%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>> .
>>>>>
>>>>>
>>>>>
>>>> -- 
>>>> 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 view this discussion on the web visit 
>>>> https://groups.google.com/d/msgid/modwsgi/5cb92649-cb87-4d82-a74f-5aebeac2f90c%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/modwsgi/5cb92649-cb87-4d82-a74f-5aebeac2f90c%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>>>
>>>>
>>> -- 
>>> 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 view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/modwsgi/61105e58-3f62-409d-a224-afa986c769c5%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/modwsgi/61105e58-3f62-409d-a224-afa986c769c5%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>>
>>>
>> -- 
>> 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 view this discussion on the web visit 
>> https://groups.google.com/d/msgid/modwsgi/707a3fe4-b289-4f8d-9166-d57c5687ceb9%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/modwsgi/707a3fe4-b289-4f8d-9166-d57c5687ceb9%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>>
>>
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/modwsgi/be886f37-3e60-4b85-8f0a-971c6bcd8e4c%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/modwsgi/be886f37-3e60-4b85-8f0a-971c6bcd8e4c%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
>
>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/modwsgi/2dc3154b-d634-464d-aa3a-39c33b394057%40googlegroups.com.

Reply via email to