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 <anurag....@ <>gmail.com >>>> <http://gmail.com/>> 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 <anurag....@ <>gmail.com >>>>> <http://gmail.com/>> 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 >>>>> >>>>> <https://modwsgi.readthedocs.io/en/develop/user-guides/frequently-asked-questions.html> >>>>> and >>>>> https://modwsgi.readthedocs.io/en/develop/user-guides/configuration-issues.html >>>>> >>>>> <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 mod...@ <>googlegroups.com <http://googlegroups.com/>. >>>>> 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 mod...@ <>googlegroups.com <http://googlegroups.com/>. >>>> 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] > <mailto:[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/15916871-28BA-4E30-9A89-AC1BAD347A73%40gmail.com.
