I have a Flask site running on Apache with mod_wsgi. The app is using the create_app() factory method to load.
When it starts, it also loads a Flask-APScheduler job that runs every minute.
The job runs just fine , making a log entry every minute.
BUT, if I restart Apache then the job will never run until someone visits the site and triggers my code to run, presumably then enabling the job.
Is there a way to configure Apache /mod_wsgi so my Flask App loads upon Apache restart without a user having to go to the site?
Related
I am trying to update the website hosted on my Apache server (running on Fedora Server).
I tried doing both system restart httpd and system reload httpd, but when I open up a web browser and go to the site's IP address, the changes haven't applied. I viewed the source to confirm that the updated code wasn't there, and indeed the updated code was not there.
It seems like the .htaccess was working, it just hadn't "kicked in" yet I guess. I set the max-age to 10 and the updates applied.
I have downloaded Apache OFBiz 16 on a machine, unzipped it in a directory, loaded default data using loadDefault option of gradlew.
After that I ran ofbiz using gradlew ofbiz. Doing this successfully runs the ofbiz and I can access the application from localhost as well as from the other machines on the same network using http://IP:8080/appname and https://IP:8443/appname.
But after some period of time, ofbiz hangs and the requests no longer seem to be completed and they seem to be loading for ever. It seems to me that problem arises when I access the OFBiz on https but problem starts to appear after some time of deployment. Initially both http and https seems to work fine.
Can anyone point out, what could be the problem?
The problem is that ofbiz uses
DelegatorFactory.getDelegator()
to find/create asynchronously in database using a single daemon thread. When the base delegator is intially absent, ofbiz will block trying to create one by using the same daemon thread--which is already being used. Hence, ofbiz is deadlocked.
* Please share your server logs*
I have a php script which runs as the Apache daemon user, to first remove any existing crontabs that might be already installed by the daemon user, then adding the new crontab.
I wish to evoke this only once when my PHP Slim web application loads for the first time, ideally as part of the Apache startup.
It seems that putting it anywhere in the index.php file (either directly or via a require file) doesn't prevent the crontab script from being constantly reloaded. I've tried using $GLOBAL with an if statement, which unfortunately I haven't been able to formulate a working solution, however there must be something more rudimentary which allows me to invoke a php script just once after Apache has been restarted?
Ideally I'd rather not modify the Apache startup script since I wish to keep everything within the slim web application itself (for source control purposes).
I've followed the instructions outlined in this answer to prevent Passenger from shutting down my app after not being used for a few minutes. However, none of this has worked.
If I refresh my website (which is just served locally on my Mac on Apache) after about 1 minute, it takes it about 6 seconds to load. After that long load, the site is now fast and everything is good. If I let it sit for another minute, refreshing again takes another 6 seconds.
Here is my /etc/apache2/other/Passenger.conf file:
LoadModule passenger_module /Users/maq/.rvm/gems/ruby-2.0.0-p247/gems/passenger-4.0.14/buildout/apache2/mod_passenger.so
PassengerRoot /Users/maq/.rvm/gems/ruby-2.0.0-p247/gems/passenger-4.0.14
PassengerDefaultRuby /Users/maq/.rvm/wrappers/ruby-2.0.0-p247/ruby
PassengerSpawnMethod smart
PassengerPoolIdleTime 1000
RailsAppSpawnerIdleTime 0
PassengerMaxRequests 5000
PassengerMaxPoolSize 30
PassengerMinInstances 1
PassengerEnabled on
And I have restarted Apache after changing all these settings.
Any ideas what else it could be?
Update:
I tried going the cron job route, where I run a cron job every minute to access the web page and make sure it stays alive. Interestingly enough, this does not work either.
It accesses the web page properly, and I see in my logs that the page is being accessed every minute, however every time I try to access it in the browser after a minute or so of user-generated activity, there is that 6 second load up. What can this be?
Note: I am using Rails 4.0.
It turns out the cause of my issues was not Passenger, but Apache and DNS.
It's a Mac OSX issue, and you can find out more about the problem/solution here:
http://clauswitt.com/fixing-slow-dns-queries-in-os-x-lion.html
Basically, if you have an entry in your /etc/hosts file called:
127.0.0.1 railsapp.local
you need to add its IPv6 counterpart so that the system doesn't go performing a remote DNS query:
fe80::1%lo0 railsapp.local
I was hoping someone could help me figure out why my application keeps timing out.
It is built using Zend Framework.
I'm trying to run a script that takes a few minutes to finish.
It works fine on my local machine (MAMP) but times out on the prod server (Ubuntu).
The relevant php.ini settings on both servers are:
max_execution_time = 600
max_input_time = 600
memory_limit = 512M
post_max_size = 8M
It should run for 10 minutes before timing out right?
On the Ubuntu server it'll only run for 1-2 minutes and then time out with this message printed in the middle of the browser:
"Backend server did not respond in time.
App server is too busy and cannot handle requests in time."
Pretty sure it's a Zend message but I can't find anything about it on the internet.
Thank you very much for any help.
That message looks like it's from mod_fastcgi.
When you run PHP under FastCGI (or you run anything under FastCGI), the PHP script is a separate entity from the web server. You've configured your PHP process to run for up to 10 minutes, but Apache/mod_fastcgi is configured to only wait some shorter period for your PHP script to start returning data.
The idea is to insulate the apache process from external processes that go off into the weeds never to return (eventually, apache would run out of listeners)
If you have access to the FastCGI configuration section of httpd.conf, check out the values for -appConnTimeout or -idle-timeout.
Unfortunately (or fortunately, if you're a sysadmin at some hosting company), you can't override these settings via .htaccess or even per virtualhost. At least, not according to the documentation
Turns out it was nginx running on the load balancer.
The error was coming from nginx which is running under scalr. Hence the "Backend server did not respond in time. App server is too busy and cannot handle requests in time." - a scalr error.
Once the proxy_read_timeout setting was raised in the nginx config the script stopped timing out.
Thanks for the scalr link above - pointed me in the right direction.