1x PassengerPreStart no error but no prespawn, 2x PassengerPreStart gives error (still no prespawn(s))

[Matt Shanks]

I'm having a problem with PassengerPreStart not working in either combination.

Server details:
Centos 7, Passenger 5.0.28, Apache 2.4.6
Passenger installed with yum. It is working (passenger-status shows expected output when used) ok, both sites work fine.

First, a single vhost and 1 PassengerPreStart use:

vhost.conf:

<VirtualHost 172.16.198.57:80>
  ServerName operations.example.co
  DocumentRoot /home/redmine/app/public
  <Directory /home/redmine/app/public>
    AllowOverride all
    Options -MultiViews
    Require all granted
  </Directory>

  PassengerFriendlyErrorPages on
  PassengerBaseURI /home/redmine/app/public
  PassengerMinInstances 1
</VirtualHost>
PassengerPreStart http://operations.example.co/

I start apache, all starts ok, no errors. Passenger is started.

passenger-status shows 0 app groups, 0 processes.

I then go to 172.16.198.57, wait 20 seconds, the page loads.

passenger-status shows 1 app group, 1 process for /home/redmine/app.

So no error but it didn't seem to work.

I then added a second vhost:

<VirtualHost 172.16.198.57:82>
  ServerName operations.example.co
  DocumentRoot /home/tracks/app/public
  <Directory /home/tracks/app/public>
    AllowOverride all
    Options -MultiViews
    Require all granted
  </Directory>

  PassengerFriendlyErrorPages on
  PassengerBaseURI /home/tracks/app/public
  PassengerMinInstances 1
</VirtualHost>
PassengerPreStart http://operations.example.co:82/

Now when I restart httpd, error log shows:

/usr/share/passenger/helper-scripts/prespawn:131:in `initialize': Connection refused - connect(2) (Errno::ECONNREFUSED)
    from /usr/share/passenger/helper-scripts/prespawn:131:in `new'
    from /usr/share/passenger/helper-scripts/prespawn:131:in `rescue in connect'
    from /usr/share/passenger/helper-scripts/prespawn:129:in `connect'
    from /usr/share/passenger/helper-scripts/prespawn:89:in `socket'
    from /usr/share/passenger/helper-scripts/prespawn:108:in `head_request'
    from /usr/share/passenger/helper-scripts/prespawn:171:in `<main>'

Same results if I change PassengerPreStart to use http://172.16.198.57(:82)/

Both scenarios produce the same results regardless of adding 127.0.0.1 operations.example.co to/etc/hosts or not (no idea if that's relevant, but thought I should try!).

Any suggestions / ideas please? Hope I've included all the relevant information, sorry if I missed anything.

[Daniel Knoppel]

PassengerBaseURI /home/tracks/app/public

Doesn't look correct. Not sure why you're using it at all if you're running the site on the root / (rather than a suburi)

- Daniel

[Matt Shanks]

Ah sorry, that was left over from when the directory structure was different. Have removed those entries and added PassengerRuby as per the link.

I've also simplified by commenting out the second vhost so just working with the redmine one (172.16.198.57:80). No prespawn but no error with both PassengerPreStart http://172.16... or http://operations.cfts.co/

[Daniel Knoppel]

If the config is correct then the next suspect would be a routing issue, i.e. the request not ending up at the right place.

First of all, I'm assuming your application actually lives on http://172.16.198.57, and not behind some redirect from there (PassengerPreStart requires an url that the application actually handles, as documented)

You mentioned "going to 172.16.198.57", but did you try that from the server where Passenger runs? E.g. `curl http://172.16.198.57:80` from the server you have Passenger running?

- Daniel

[Matt Shanks]

Yes the application is on there - no redirects happening.

Sorry poor use of words, visiting http://172.16.198.57 from my computer loads the application's homepage, and similarly 'curl http://172.16.198.57' on the server returns it fine too.

[Daniel Knoppel]

Hmm, I was going by the documentation, but after inspecting the prestarter script it's actually a pretty naive implementation that always connects to 127.0.0.1 no matter the URL. So I think that would create a routing mismatch with your VirtualHost block that is set to 172.16.198.57.

What I would advise is to try to extend the block to capture requests from 127.0.0.1 as well. I.e.:

<VirtualHost 127.0.0.1:80 172.16.198.57:80>

Then just set the PassengerPreStart url as you have it in your original config (i.e. equal to the server name = operations.example.co). 

If you still have the /etc/host mapping of  operations.example.co to 127.0.0.1 you can discard that because operations.example.co isn't used by the current script anyway.

Let me know if this works, I've reported an issue based on some tests I ran myself, if you can confirm the above solves it for you then we've encountered the same thing.

- Daniel

[Matt Shanks]

That worked!

For summation:

No /etc/hosts entry, site accessed by IP, Apache (2.4.6), Passenger 5.0.28.

Vhost.conf

<VirtualHost 127.0.0.1 172.16.198.57:80> 

ServerName operations.cfts.co
  DocumentRoot /home/redmine/app/public
  PassengerRuby /usr/local/rvm/gems/ruby-2.3.0/wrappers/ruby 

 <Directory /home/redmine/app/public>
    AllowOverride all
    Options -MultiViews
    Require all granted
  </Directory> 

  PassengerFriendlyErrorPages on
  PassengerMinInstances 1
</VirtualHost>
PassengerPreStart http://operations.cfts.co/ 

[Matt Shanks]

Sorry I forgot to say thank you Daniel. Thank you!

I reintroduced the second host and that is working fine as well.

<VirtualHost 127.0.0.1:82 172.16.198.57:82>

    ...

</VirtualHost

PassengerPreStart http://operations.example.co:82/

Added 'Listen 127.0.0.1:82' to the httpd.conf, without 'curl 127.0.0.1:82' connection refused.

Thank you again Daniel.

[Daniel Knoppel]

Great to hear, Matt. Welcome! :)

- Daniel