Should use 'bundle exec passenger'

[batamire]

passenger stderr: /home/xxx/.rvm/scripts/set: line 19: exec: passenger: not found

Using capistrano/bundler my bundled gems get installed to /home/xxx/apps/xxx/shared/bundle/ruby/2.2.0/gems/passenger-5.0.4 and are not in gem list

[gustaflindqvist]

I have the same problem with exec: passenger: not found in version 0.0.4.

[betesh]

Please upgrade to 0.0.5 and pay special attention to https://github.com/capistrano/passenger#note-for-rvm-users and let me know the results please. Are you using capistrano-rvm?

[davidmles]

I'm using rbenv and I have the same problem:

[a5f6fefa] Running RBENV_ROOT=~/.rbenv RBENV_VERSION=2.2.1 ~/.rbenv/bin/rbenv exec passenger -v as deploy@myhost
DEBUG [a5f6fefa] Command: ( RBENV_ROOT=~/.rbenv RBENV_VERSION=2.2.1 RBENV_ROOT=~/.rbenv RBENV_VERSION=2.2.1 ~/.rbenv/bin/rbenv exec passenger -v )
DEBUG [a5f6fefa]    rbenv: passenger: command not found
(Backtrace restricted to imported tasks)
cap aborted!
SSHKit::Runner::ExecuteError: Exception while executing as deploy@myhost: passenger exit status: 127
passenger stdout: Nothing written
passenger stderr: rbenv: passenger: command not found

SSHKit::Command::Failed: passenger exit status: 127
passenger stdout: Nothing written
passenger stderr: rbenv: passenger: command not found

Tasks: TOP => passenger:restart
(See full trace by running task with --trace)
The deploy has failed with an error: Exception while executing as deploy@myhost: passenger exit status: 127
passenger stdout: Nothing written
passenger stderr: rbenv: passenger: command not found

Downgrading to 0.0.4 fixes the issue:

[32a0f785] Running /usr/bin/env passenger -v as deploy@myhost
DEBUG [32a0f785] Command: ( RBENV_ROOT=~/.rbenv RBENV_VERSION=2.2.1 /usr/bin/env passenger -v )
DEBUG [32a0f785]    Phusion Passenger version 5.0.6
DEBUG [32a0f785]    
DEBUG [32a0f785]    
DEBUG [32a0f785]    "Phusion Passenger" is a trademark of Hongli Lai & Ninh Bui.
DEBUG [32a0f785]    
DEBUG [32a0f785] Finished in 0.125 seconds with exit status 0 (successful).

[batamire]

Still the same. I don't see anything in git diff that touches this issue? e.g. bundle exec
I am using capistrano/rvm.

[betesh]

@davidmles The issue with capistrano-passenger v0.0.5 is that it makes an assumption that if you're using rbenv, you installed passenger via rbenv. There's a discussion going on in #9 about this (from here down). We already addressed a similar issue with RVM. PR's welcome.

@batamire Are you installing passenger during the deployment? This gem assumes it's already installed.

[batamire]

@betesh Yes, I am installing it as part of capistrano/bundler task. It gets installed to /home/xxx/apps/xxx/shared/bundle/ruby/2.2.0/gems/passenger-5.0.4 and is not in $PATH and is only accessible with bundle exec passenger ... within current_path.

workaround in deploy.rb

set :bundle_path,     nil
set :bundle_binstubs, nil
set :bundle_flags,    '--system'

so the gems are installed in rvm's ruby@gemset instead of shared/bundle

offtopic Shouldn't set :passenger_restart_options, -> { "#{deploy_to} --ignore-app-not-running" } use current_path instead?

[betesh]

@batamire I assumed nobody would ever do that because you then need to update your Apache / nginx config manually after running passenger-install-nginx (or apache) -module, which doesn't fit into an automated deployment process, especially if you want to avoid deploying with root privileges. How do you work around that? I don't think this is a common use case that we need to support, but I am eager to here how it is possible.

As for using deploy_to instead of current_path, I think you are right but the original contributor wrote it that way and I left it as is. Unless you are deploying multiple projects to the same deploy_to (_bad idea_), when would it ever make a difference?

[batamire]

I'm using passenger-standalone (multiple apps on server) with one reverse proxy - nginx. So I try to avoid having passenger gem in multiple locations (bundle and gemset).

No2: If I don't explicitly start passenger with passenger start current_path or with --restart-dir i can't restart it by touching tmp/restart.txt - it get's tied to release_path instead.
And I just can't get new passenger-config restart-app to work no matter what options I pass: It appears that multiple Phusion Passenger instances are running. Please select a specific one by passing: --instance <NAME>. Instance names are just random hashes... Do I need to start it differently (giving it an instance name)?

[betesh]

If you are running multiple instances of passenger, that is definitely beyond the scope of this gem.

IMO it does not make sense to be running multiple instances. Passenger is specifically designed for high-performance multi-threading within a single instance, so I suspect multiple instances will just degrade performance. Please address that issue first before we continue this conversation.

[batamire]

Sorry for lack of clarity: I'm running multiple apps, one passenger instance per app. Each app has it's own /home/username and each passenger-standalone is run as different user. It is possible for a user to have multiple apps in his home directory, thus each running a single passenger instance (in future).

Running passenger-config restart-app lists all passenger 'instances' run by all users. No matter what options I give it. No matter as what user I run it.

[betesh]

@batamire It sounds like the obstacle is with the passenger-config restart-app command itself, not with capistrano. Correct?

[batamire]

Yep! And it was offtopic ;)

What really confuses me is using bundle exec passenger start in every deploy doc, listing it in Gemfile but with capistrano/passenger you have to have passenger installed outside the bundle. If so, maybe you could just put it in Readme. So far I liked capistrano/bundler approach. Thank you for your time!

[betesh]

So is this issue ready to be closed? If not, please give me a short summary of how this gem could handle your situation.

[batamire]

I edited my previous answer, that's all. Thanks.

[betesh]

Correct -- This gem assumes passenger is installed outside the bundle (we try to call passenger -v before cap bundler:install runs).

[zjx20]

I need bundle exec passenger start too. Why I have to install passenger outside of bundle?
Maybe an option to specify how to execute passenger would help.

[betesh]

@zjx20 We added a lot of complexity in order to try to handle every situation by detecting automatically instead of forcing the user to configure. It seems that there are still a lot of situations we haven't considered. I do want to be able to handle all situations, so maybe in a few days I will have time to add some code to support restarting standalone passenger.

[zjx20]

I think the best way is touch tmp/restart.txt. That is really simple and effective, works for all situations.

[betesh]

@zjx20 Use capistrano-passenger v0.0.2 if that's all you want. Later versions were designed to support passenger v5. If you are happy on v4, there's no reason to upgrade capistrano-passenger.

[japodacaj]

The version check also doesn't seem to take into account environments that run Passenger from the system version of Ruby, like specified in the official Passenger docs.

To work around this, install the same version of Passenger to your local version of Ruby as the one you're running under the system in order to pass version checking.

Maybe if :passenger_restart_with_sudo is set to true, it should check the system version or bypass?

[soundasleep]

I had passenger installed system-wide using sudo as part of previously installing Redmine, so I was falling into this problem too.

I didn't like the idea of giving my deploy user password-less sudo access, so I found that using the deprecated way (touching tmp/restart.txt) to restart Passenger works perfectly as a workaround. Put this in your deploy.rb:

set :passenger_restart_with_touch, true