load realpath for require paths symlinked

[Martin288]

fix #1272

[grosser]

FYI trying to fix this whole bundler mess by unsetting bundler ENV vars on restart ... would that solve your issue too ?

# config/puma.rb
Puma::Runner.prepend(Module.new do
  def before_restart
    ENV.replace(Bundler.clean_env)
    super
  end
end)

[Martin288]

@grosser thanks. but I don't know if there is any side effect that unsetting bundler ENV vars, have you tried it?

[grosser]

yes, using that in prod since ~1 year
only issue is that restarts might not know how to restart so you have to use --restart-cmd 'bundle exec puma'

[Martin288]

@grosser great! Will use it soon. But I still hope it can be solved from the puma repository, however, your solution is a good temporarily solution.

[grosser]

once rubygems/bundler#5700 is resolved puma will work like this ... but there will be solve fallout with puma forgetting how to restart ... so ideally we'd fix that up properly until then :)

[stereobooster]

@grosser by idea this is same as your code, but less hacky

# config/puma.rb
on_restart do
  ENV.replace(Bundler.clean_env)
end

[x-yuri]

@grosser I'd rather avoid cleaning env. By the way, it's deprecated for one reason or another. Additionally, it makes restart_command mandatory.

Also, I can confirm that PR by @Martin288 fixes it for cluster mode + prune_bundler. Since in this case puma restarts itself before starting workers. But unfortunately not for other cases. The solution might be to set instance variable on Puma::Launcher.initialize with Pathname($0).realpath.to_s. And use that instead of $0 down the road.

UPD And at first glance the following changes fixes it for single mode, cluster mode, cluster mode + prune_bundler when puma is invoked with bundle exec puma:

--- restart-puma/bundle/ruby/2.5.0/gems/puma-3.11.4/lib/puma/launcher.rb.orig	2018-07-06 09:52:32.450769132 +0300
+++ restart-puma/bundle/ruby/2.5.0/gems/puma-3.11.4/lib/puma/launcher.rb	2018-07-06 09:55:35.604106620 +0300
@@ -8,6 +8,8 @@
 
 require 'puma/binder'
 
+require 'pathname'
+
 module Puma
   # Puma::Launcher is the single entry point for starting a Puma server based on user
   # configuration. It is responsible for taking user supplied arguments and resolving them
@@ -47,6 +49,7 @@
       @argv          = launcher_args[:argv] || []
       @original_argv = @argv.dup
       @config        = conf
+      @arg0 = Pathname($0).realpath.to_s
 
       @binder        = Binder.new(@events)
       @binder.import_from_env
@@ -354,10 +357,10 @@
       # it the same, otherwise add -S on there because it was
       # picked up in PATH.
       #
-      if File.exist?($0)
-        arg0 = [Gem.ruby, $0]
+      if File.exist?(@arg0)
+        arg0 = [Gem.ruby, @arg0]
       else
-        arg0 = [Gem.ruby, "-S", $0]
+        arg0 = [Gem.ruby, "-S", @arg0]
       end
 
       # Detect and reinject -Ilib from the command line, used for testing without bundler

Additionally, I've discovered that prune_bundler makes puma from ~/.gem/ruby/2.5.1 start, not from vendor/bundle/ruby/2.5.0. Is that expected?

[grosser]

yeah either way is fine, this whole realpath mess goes away when deploying using docker anyway, so meh :)

[x-yuri]

With the following puma config (prune_bundler and workers are from the issue):

require 'puma/runner'
Puma::Runner.prepend(Module.new do
    def before_restart
        ENV.replace(Bundler.clean_env)
    super
  end
end)
workers 2
prune_bundler

It (puma-3.12.0) fails to restart but for another reason:

/home/user/app/current/config/puma/production.rb:19:in `before_restart': uninitialized constant #<Class:#<Puma::DSL:0x007fe32aeb7ef8>>::Bundler (NameError)
    from /home/user/app/releases/11/vendor/bundle/ruby/2.3.0/gems/puma-3.12.0/lib/puma/launcher.rb:194:in `run'
    from /home/user/app/releases/11/vendor/bundle/ruby/2.3.0/gems/puma-3.12.0/lib/puma/cli.rb:78:in `run'
    from /home/user/app/releases/11/vendor/bundle/ruby/2.3.0/gems/puma-3.12.0/bin/puma-wild:31:in `<main>

So, I remove prune_bunder, and this error goes away, but we're back at square one. The issue is not resolved. I try it without workers 2, same result. The result is also identical with the following block:

on_restart do
  ENV.replace(Bundler.clean_env)
end

So, it must be safe to assume, that rubygems/bundler#5700 has nothing to do with it. And if you look at the report closely enough, you'll see that it has nothing to do with environment variables.

[nateberkopec]

Closing this, as I think we're going to go with a different approach from #1105 to fix this code.