Hello guys, I'm configuring a new Galaxy production instance and I did many tries with uWSGI. I have found that the -d (or --daemonize) option that the Galaxy wiki suggests should be replaced with the --daemonize2 option. In fact, when using the -d option for uWSGI it often happens that some (or sometimes all) of the uwsgi workers does not correctly bind to the Galaxy app when uWSGI is loaded just after Galaxy, as when you set up an init.d galaxy launch script. I don't know exactly why it happens but I think it has to do with the fact that uWSGI daemonize before the Galaxy server is fully loaded and this was giving me a lot of headaches. Example: This is a typical uWSGI log that I had at launch when using -d (or --daemonize) using six workers spawned uWSGI master process (pid: 32142) spawned uWSGI worker 1 (pid: 32183, cores: 4) spawned uWSGI worker 2 (pid: 32184, cores: 4) spawned uWSGI worker 3 (pid: 32185, cores: 4) galaxy.queue_worker INFO 2015-09-22 13:53:22,348 Binding and starting galaxy control worker for main.1 galaxy.queue_worker INFO 2015-09-22 13:53:22,351 Binding and starting galaxy control worker for main.2 spawned uWSGI worker 4 (pid: 32188, cores: 4) spawned uWSGI worker 5 (pid: 32189, cores: 4) galaxy.queue_worker INFO 2015-09-22 13:53:22,356 Binding and starting galaxy control worker for main.4 spawned uWSGI worker 6 (pid: 32191, cores: 4) *** Stats server enabled on 127.0.0.1:9191 fd: 20 *** galaxy.queue_worker INFO 2015-09-22 13:53:22,360 Binding and starting galaxy control worker for main.5 As you can see worker 3 and worker 6 are not bound to galaxy. And this behaviour is not deterministic: sometimes more workers are missing and in some cases I had no workers bound to Galaxy and so it was not accessible. Some other times instead all the workers were correctly bound to Galaxy. Using --daemonize2 ensures that uWSGI daemonize after the app (Galaxy) is fully loaded thus removing this strange behaviour. Best, Federico