I've done a new install of nginx 1.6.3 and passenger 5.0.15 on Ubuntu 14.04 from source in order to add tracing components from AppNeta for my ROR 4.2 app on one of my servers. Nginx and passenger are running and serving pages. I am getting the trace data for server monitoring. All seems well,
However, when I run "passenger-status" (as root), I get the following:
ERROR: Phusion Passenger doesn't seem to be running. If you are sure that it is running, then the causes of this problem could be:
You customized the instance registry directory using Apache's PassengerInstanceRegistryDir option, Nginx's passenger_instance_registry_dir option, or Phusion Passenger Standalone's --instance-registry-dir command line argument. If so, please set the environment variable PASSENGER_INSTANCE_REGISTRY_DIR to that directory and run passenger-status again.
The instance directory has been removed by an operating system background service. Please set a different instance registry directory using Apache's PassengerInstanceRegistryDir option, Nginx's passenger_instance_registry_dir option, or Phusion Passenger Standalone's --instance-registry-dir command line argument.
The problem with this is that it seems to be blocking capistrano deploys; this same error is displayed by cap before exiting.
Passenger is running (it's in the ps output and pages are being served). I just need to tell passenger-status where to find the current running instance. (This is from the Design and Architecture documentation.) Therefore, it seems that setting this instance registry directory value is the required step. But to what value?
According to the Nginx Reference, the defaults are /tmp and /var/run/passenger-instreg And I've found an instance directory in /tmp. So, I've tried setting the PASSENGER_INSTANCE_REGISTRY_DIR to a number of different values:
/tmp
/tmp/passenger.JxmCeiA (the current instance directory, but this changes with each startup of Nginx)
I've even tried creating a directory at /run/passenger, setting that value in the nginx configuration file and restarting nginx. The temporary directory is being created, but passenger-status still gives the same message. Even if I use the /opt/passenger-5.0.15/bin/passenger-status script to make sure I'm using the latest version of that script.
There are some configuration values in the original 'location.ini' directory for passenger, but none were the instance registry directory, so there was nothing to reuse.
Interestingly, the /opt/passenger-5.0.15/lib/phusion_passenger/nginx/config_options.rb file does not have an entry for passenger_instance_registory_dir. It has other nginx configuration options, I would have expected it to have this one as well.
I've tried setting the environment variable as well as the Nginx passenger_instance_registry_dir option, but I must be missing something in my understanding because I can't seem to connect the passenger-status command with the current running instance.
Any help would be greatly appreciated.
Passenger author here.
/tmp/passenger.JxmCeiA is an example of an instance directory. This changes indeed with every startup (because it is specific to an instance).
The parent directory (the directory in which instance directories are located) is the instance registry directory. So in your case, the instance registry directory that is being used is /tmp.
I'm guessing that you have some kind of Passenger installation version mismatch. We've changed the structure of the instance directory a few times in the past, and every time we did this we bump an internal version number to indicate that it's incompatible with previous Passenger versions. Can you double check the following?
Does Passenger appear to be otherwise running correctly?
What Passenger version is compiled inside Nginx?
What is your passenger_root set to? Does it match the Passenger version compiled inside Nginx?
Where is the full path to the first passenger-status in PATH? Does it match passenger_root?
You also seem to be mixing the Phusion Passenger APT repository with source tarball install. Having multiple installations around is generally a bad idea. Try cleaning up your other installs so that you only end up with one.
Also check whether you are setting the PASSENGER_INSTANCE_REGISTRY_DIR environment variable correctly. Note that sudo nukes environment variables, so you need to run passenger-status like this:
# Correct:
sudo env PASSENGER_INSTANCE_REGISTRY_DIR=/tmp passenger-status
# Incorrect, sudo nukes environment variables
export PASSENGER_INSTANCE_REGISTRY_DIR=/tmp
sudo passenger-status
Regarding lib/phusion_passenger/nginx/config_options.rb: that file mainly lists per-server and per-location config options. Many config options in the main context are either not yet ported to the config_options.rb system, or not possible because they require custom attention. At present, passenger_instance_registry_dir is implemented in ext/common/nginx/Configuration.c. As we continue to cleanup and refactor the codebase, this option may eventually be moved to config_options.rb.
In case anyone else is having this problem when starting Passenger using a systemd service, this might be due to systemd's private /tmp. The problem was solved by adding PrivateTmp=false to the service file.
Source
step one check phusion passenger is installed correctly
sudo passenger-config validate-install
"if you see an ouput saying, 'Everything is looks good :-)'" then you are fine, if not you need to reinstall phusion passenger, refer to https://www.phusionpassenger.com/library/walkthroughs/start/
step two check the phusion passenger memory status
sudo passenger-memory-stats
"if you see processes running, then that's good, if not you either have to start some passenger app, or install nginx or apache with extra library for them. For nginx you need nginx and the nginx-extras".
step three uncomment the passenger_root in the nginx.conf file (for ubuntu it's usually /etc/nginx/nginx.conf) or the apache.conf file
restart nginx or apache
sudo service nginx restart # (or systemctl restart nginx, for new version of linux such as ubuntu 15.04, CentOS7)
now you can run
passenger-status
the error should go away now. The mostly likely output you will get is saying "Phusion Passenger is currently not serving any applications."
I'm running Passenger in Nginx integration mode, on Ubuntu 20.04 and I've installed it via apt from the official repos.
What worked for me was adding this to /etc/nginx/conf.d/mod-http-passenger.conf :
passenger_instance_registry_dir /tmp;
Restarting passenger the Capistrano way from the command line should now work:
$ passenger-config restart-app <your_app's_root_path> --ignore-app-not-running
If this works, Capistrano deployments should now work again.
Related
I'm using passenger and nginx to host a rails app and unfortunately I'm receiving an error when I run passenger-status. I built a new server from a chef script I have and suspect I do have something misconfigured.
Versions:
Phusion Passenger Enterprise 5.0.28
nginx version: nginx/1.10.0
The error:
ERROR: Phusion Passenger doesn't seem to be running. If you are sure
that it is running, then the causes of this problem could be:
You customized the instance registry directory using Apache's PassengerInstanceRegistryDir option, Nginx's
passenger_instance_registry_dir option, or Phusion Passenger
Standalone's --instance-registry-dir command line argument. If so,
please set the environment variable PASSENGER_INSTANCE_REGISTRY_DIR to
that directory and run passenger-status again.
The instance directory has been removed by an operating system background service. Please set a different instance registry directory
using Apache's PassengerInstanceRegistryDir option, Nginx's
passenger_instance_registry_dir option, or Phusion Passenger
Standalone's --instance-registry-dir command line argument.
When I run ps aux | grep Passenger I get the following results:
root 11877 0.0 0.1 431348 9368 ? Ssl Jun21 0:01
Passenger watchdog
root 11880 0.0 0.1 859564 11568 ? Sl Jun21 0:16
Passenger core
nobody 11885 0.0 0.1 439924 10232 ? Sl Jun21 0:03
Passenger ust-router
I didn't actually specify passenger_instance_registry_dir or use the --nstance-registry-dir command so I'm not sure what change to make.
My rails app does respond interestingly enough, although it does throw up an error page (and logs don't indicate why, which makes me think nginx is just serving it).
I had the problem on apache. Installed from gem, no clue what went wrong.
The fix was to specify the PassengerInstanceRegistryDir as per: https://www.phusionpassenger.com/library/config/apache/reference/#passengerinstanceregistrydir
I opted for non /tmp as there were some hints on the net that that could be the problem. Just have to create the directory you specify (eg in /var/run)
According to the documentation at https://www.phusionpassenger.com/documentation/Users%20guide%20Nginx.html#env_vars_passenger_apps 15.3.5 Phusion Passenger should be reading environmental variables from .bashrc. I am trying to run a rails 4.2 application from a user account named rails using nginx and Phusion passenger and get a 502 bad gateway error when I try to load it in the browser. The process operates under the correct user. When I open a ruby console in the rails app directory I see the environment variables from my bashrc including secret_key_base. However when I tail my nginx log the error I get is that it is not able to find secret_key_base. I have tried adding this elsewhere including /etc/bash.bashrc and /etc/nginx.conf.
I have found the answer to this horrible question. The answer is at https://github.com/phusion/passenger/wiki/Debugging-application-startup-problems under the heading "Early Termination in Bash". It turns out that the Ubuntu .bashrc does not run if the shell is not interactive. Phusion Passenger does not run in an interactive shell. Therefore we do not load these environment variables for the Phusion Passenger process.
Mike's comment was on track. If you are using rvm then nginx points to a ruby script that you can put the environment variables in before ruby starts.
passenger_ruby /home/rails/.rvm/gems/ruby-2.2.1#was_i_towed/wrappers/ruby;
Is a line in my nginx.conf file. If I open this wrapper in vi or nano then I can add the EXPORT SECRET= to the top of the file and it works.
Other literature suggests that setting the environment variables in /etc/environment should also work.
This issue should also be rendered moot when upgrading to Phusion Passenger 5 which has a facility for specifying environment variables in nginx.conf.
We are running ubuntu servers with Nginx + Phusion Passenger for our rails 3.0x apps.
I have an environment variable set in /etc/environment on the test machines:
MC_TEST=true
If I run a console (bundle exec rails c) and output ENV["MC_TEST"] I see 'true'.
But, if I put that same code on a page ( <%= ENV["MC_TEST"] %> ) it doesn't see anything. That variable does not exist.
Which leads me to question:
1 - What is the proper way to get environment variables into passenger with nginx (not apache SetEnv)?
2 - Why does Passenger not have a proper environment?
Passenger fusion v4+ enables reading of environment variables directly from bashrc file. Make sure that bashrc lives in the home folder of the user under which passenger process is executed (in my case, it was ubuntu, for ec2 linux and nginx)
Here is the documentation which goes into details of bashrc
I've the same problem with you when use passenger with nginx and nginx init script on ubuntu.
The reason is that I use sudo service nginx restart(installed by init script) to start up nginx and
it was running by root and the root did not get your login user environment variable.
There are two solutions for this.
One is running nginx manually.
sudo service nginx stop
sudo -E /path/to/your/nginx
one is add env to your nginx init script
export MC_TEST=true
The latter solution is somehow ugly, But it works. And I think the better way is found a configuration to tell the init script to preserve the login user env.
I got another ugly solution.
env_file = '/etc/environment'
if File.exist?(env_file)
text = File.open(env_file).read
text.each_line do |line|
key, val = line.split('=', 2)
ENV[key] = val.strip
end
end
With nginx you can use the variable passenger_env_var to it. See an example below
passenger_env_var GEM_HOME /home/foo/.rbenv/rubygems;
passenger_env_var GEM_PATH /home/foo/.rbenv/rubygems/gems;
So for your case
passenger_env_var MC_TEST true;
Okay, so I'm following a guide to get set up with a Rails production server, and it says the following in the Apache2 setup:
We have to create a virtual host by creating a file in the "/etc/apache2/sites-available" directory (we will name it "site" - the file won't have any extension but it will be a text file).
$ sudo nano /etc/apache2/sites-available/site (this will create the file named "site" - can be any name - AND open it for editing)
Copy and paste this into that file (compare also with what the notes after installing mod_rails tells you):
VirtualHost *:80>
ServerName localhost
ServerAlias localhost
DocumentRoot /home/user/public_html/site/public
/VirtualHost>
When I was first testing the waters with Apache I did as it said, making a fake scaffolded Rails app called "site". Now I want to use my real site, which we'll call "realthing." So I did
# sudo mv /etc/apache2/sites-available/site /etc/apache2/sites-available/realthing
And put my new settings into the renamed file. So far so good.
Then I went to restart Apache. Problems begin.
# sudo a2ensite realthing
Enabling site realthing.
To activate the new configuration, you need to run:
service apache2 reload
Okay, I can do that.
# sudo service apache2 reload
apache2: Syntax error on line 230 of /etc/apache2/apache2.conf: Could not open configuration file /etc/apache2/sites-enabled/site: No such file or directory
Action 'configtest' failed.
The Apache error log may have more information.
...fail!
Fail indeed. Nothing I can seem to do can get this thing to restart without flipping out about the missing "site" file. I check line 230 of /etch/apache2/apache2.conf for any specific references. Nope:
Include sites-enabled/
It's a generic reference to the folder containing "site". But no mention of "site".
So what's up? How do I get Apache to forget about the fake site "site" and move on to the real thing "realthing"? It's driving me insane that even a superuser reload is failing because Apache can't find a file that as far as I can tell it has no reason to expect to find.
Even a hard
sudo service apache2 stop
and
sudo service apache2 start
doesn't work. Again with the
* Starting web server apache2
apache2: Syntax error on line 230 of /etc/apache2/apache2.conf: Could not open configuration file /etc/apache2/sites-enabled/site: No such file or directory
Action 'start' failed.
This is driving me bonkers. Any ideas?
The Apache error log may have more information.
You probably still have a symlink from sites-enabled/site to the now missing sites-available/site
I've set up Passenger in development (Mac OS X) and it works flawlessly. The only problem came later: now I have a custom GEM_HOME path and ImageMagick binaries installed in "/usr/local". I can put them in one of the shell rc files that get sourced and this solves the environment variables for processes spawned from the console; but what about Passenger? The same application cannot find my gems when run this way.
I know of two solutions. The first (documented here) is essentially the same as manveru's—set the ENV variable directly in your code.
The second is to create a wrapper around the Ruby interpreter that Passenger uses, and is documented here (look for passenger_with_ruby). The gist is that you create (and point PassengerRuby in your Apache config to) /usr/bin/ruby_with_env, an executable file consisting of:
#!/bin/bash
export ENV_VAR=value
/usr/bin/ruby $*
Both work; the former approach is a little less hackish, I think.
Before you do any requires (especially before requiring rubygems) you can do:
ENV['GEM_HOME'] = '/foo'
This will change the environment variable inside this process.
I found out that if you have root priviledges on computer then you can set necessary environment variables in "envvars" file and apachectl will execute this file before starting Apache.
envvars typically is located in the same directory where apachectl is located - on Mac OS X it is located in /usr/sbin. If you cannot find it then look in the source of apachectl script.
After changing envvars file restart Apache with "apachectl -k restart".
I've run into this issue as well. It appears that Passenger doesn't passthrough values set using the SetEnv apache directive - which is unfortunate.
Perhaps it might be possible to set environment variables in your environment.rb or boot.rb (assuming you're talking about a Rails app; I'm not familiar with Rack but presumably it has similar functionality)