Bundler error prevents phased-restarting puma after upgrading to rails 7 #2843

joker-777 · 2022-03-17T09:12:13Z

Describe the bug

We saw two different errors

158586] ! Unable to start worker
[4158586] /usr/lib/ruby/gems/3.0.0/gems/bundler-2.3.9/lib/bundler/definition.rb:481:in `materialize' [4158594] + Gemfile in context: /var/local/kenhub/kenhub.d/878/Gemfile

which should have raised this kind of error raise GemNotFound, "Could not find #{missing_specs.map(&:full_name).join(", ")}" in any of the sources"

and

[16442] ! Unable to start worker
[16442] /usr/lib/ruby/gems/3.0.0/gems/bundler-2.3.9/lib/bundler/runtime.rb:309:in `check_for_activated_spec!'

which should have raised this kind of error Gem::LoadError.new "You have already activated #{activated_spec.name} #{activated_spec.version}, but your Gemfile requires #{spec.name} #{spec.version}. #{suggestion}"

Why didn't we see these error messages in the puma logs and how can we fix them?

Puma config:

#!/usr/bin/env puma

# The directory to operate out of.
#
# The default is the current directory.
#
directory "/var/local/kenhub/kenhub"

# Set the environment in which the rack's app will run. The value must be a string.
#
# The default is "development".
#
environment ENV["RAILS_ENV"] || "development"

# Store the pid of the server in the file at "path".
#
pidfile "/var/run/puma/puma.pid"

# Use "path" as the file to store the server info state. This is
# used by "pumactl" to query and control the server.
#
state_path "/var/run/puma/puma.state"

# Redirect STDOUT and STDERR to files specified. The 3rd parameter
# ("append") specifies whether the output is appended, the default is
# "false".
#
stdout_redirect "/var/log/kenhub/puma.log", "/var/log/kenhub/puma.log", true

# Configure "min" to be the minimum number of threads to use to answer
# requests and "max" the maximum.
#
# The default is "0, 16".
#
# threads 0, 16
threads 8, 8


# Bind the server to "url". "tcp://", "unix://" and "ssl://" are the only
# accepted protocols.
#
# The default is "tcp://0.0.0.0:9292".
#
bind 'unix:///var/run/puma/puma.sock'


# === Cluster mode ===

# How many worker processes to run.  Typically this is set to
# to the number of available cores.
#
# The default is "0".
#
workers ENV["PUMA_WORKERS"] || 16

# Allow workers to reload bundler context when master process is issued
# a USR1 signal. This allows proper reloading of gems while the master
# is preserved across a phased-restart. (incompatible with preload_app)
# (off by default)

# see https://github.com/puma/puma/blob/master/docs/deployment.md#restarting
prune_bundler

To Reproduce

update rails code to rail 7
run /usr/bin/bundle exec pumactl -F config/puma.rb phased-restart

Expected behavior

phased-restart should restart all puma instances correctly

Desktop (please complete the following information):

OS: Ubuntu 20.04 with systemd
Puma Version 5.6.2

The text was updated successfully, but these errors were encountered:

joker-777 · 2022-04-06T07:34:49Z

@nateberkopec Could you please give us some guidance on how to investigate it? How can we debug certain puma instances and check why they don't phased-restart properly?

nateberkopec · 2022-04-09T15:01:33Z

@joker-777 Without an app that reproduces the issue we can't really help you, so building a minimal app which shows the issue (even intermittently) would be the place to start.

gingerlime · 2022-04-10T12:46:51Z

Hey @nateberkopec 👋 . I work with @joker-777. We completely understand the need to reproduce it. We can reproduce it some times on our staging environment, but we so far weren't able to pinpoint what triggers it, nor able to reproduce it in a sterile test-app environment unfortunately. Our app has many moving parts, so pairing it down is difficult.

In order to try to understand what triggers the problem, we were wondering if there's a way for us to somehow "query" or debug the puma workers state in some way. For example: be able to see the full path of the Gemfile and code that the worker has loaded.

We bumped into similar problems in the past, see #2018 and #2471, so my hunch is that it's somehow related to having folders with symlinks and bundler losing its orientation somehow, but unfortunately the error in the puma.log doesn't have much information to go with. Hopefully if we can gather a bit more info from the puma workers, we can then get better clues to help us reproduce it with a sample app.

nateberkopec · 2022-04-11T14:47:20Z

This error logging was added here: 04e4b1a

We could increase what's logged there, but I don't think that would help you, because you've already zeroed in on the problem.

I'm not sure what to say, you can tell me what info you want and we can add it (or you can fork, try adding the info you want, and then we can add it if it's useful)?

gingerlime · 2022-05-31T07:04:01Z

We're still bumping into this, yet it's hard to reproduce reliably, even on our staging environment. One thing that definitely jumps out however is that the raise GemNotFound, "Could not find #{missing_specs.map(&:full_name).join(", ")}" in any of the sources" from bundler doesn't seem to get logged in the puma log (or anywhere else we could find). This makes investigating even harder.

With this patch in place, we can see this in the puma.log

[159284] + Gemfile in context: /var/local/app/app.d/1239/Gemfile
[159284] ! Unable to start worker
[159284] ["/usr/lib/ruby/gems/3.0.0/gems/bundler-2.3.14/lib/bundler/definition.rb:486:in `materialize'", "/usr/lib/ruby/gems/3.0.0/gems/bundler-2.3.14/lib/bundler/definition.rb:191:in `specs'", "/usr/lib/ruby/gems/3.0.0/gems/bundler-2.3.14/lib/bundler/definition.rb:239:in `specs_for'", "/usr/lib/ruby/gems/3.0.0/gems/bundler-2.3.14/lib/bundler/runtime.rb:18:in `setup'", "/usr/lib/ruby/gems/3.0.0/gems/bundler-2.3.14/lib/bundler.rb:151:in `setup'", "/usr/lib/ruby/gems/3.0.0/gems/bundler-2.3.14/lib/bundler/setup.rb:20:in `block in <top (required)>'", "/usr/lib/ruby/gems/3.0.0/gems/bundler-2.3.14/lib/bundler/ui/shell.rb:136:in `with_level'", "/usr/lib/ruby/gems/3.0.0/gems/bundler-2.3.14/lib/bundler/ui/shell.rb:88:in `silence'", "/usr/lib/ruby/gems/3.0.0/gems/bundler-2.3.14/lib/bundler/setup.rb:20:in `<top (required)>'", "<internal:/usr/lib/ruby/site_ruby/3.0.0/rubygems/core_ext/kernel_require.rb>:85:in `require'", "<internal:/usr/lib/ruby/site_ruby/3.0.0/rubygems/core_ext/kernel_require.rb>:85:in `require'", "/var/local/app/app.d/1236/vendor/bundle/ruby/3.0.0/bundler/gems/puma-fb10563f0209/lib/puma/configuration.rb:329:in `rack_builder'", "/var/local/app/app.d/1236/vendor/bundle/ruby/3.0.0/bundler/gems/puma-fb10563f0209/lib/puma/configuration.rb:348:in `load_rackup'", "/var/local/app/app.d/1236/vendor/bundle/ruby/3.0.0/bundler/gems/puma-fb10563f0209/lib/puma/configuration.rb:270:in `app'", "/var/local/app/app.d/1236/vendor/bundle/ruby/3.0.0/bundler/gems/puma-fb10563f0209/lib/puma/runner.rb:166:in `app'", "/var/local/app/app.d/1236/vendor/bundle/ruby/3.0.0/bundler/gems/puma-fb10563f0209/lib/puma/runner.rb:170:in `start_server'", "/var/local/app/app.d/1236/vendor/bundle/ruby/3.0.0/bundler/gems/puma-fb10563f0209/lib/puma/cluster/worker.rb:58:in `run'", "/var/local/app/app.d/1236/vendor/bundle/ruby/3.0.0/bundler/gems/puma-fb10563f0209/lib/puma/cluster.rb:208:in `worker'", "/var/local/app/app.d/1236/vendor/bundle/ruby/3.0.0/bundler/gems/puma-fb10563f0209/lib/puma/cluster.rb:101:in `block in spawn_worker'", "/var/local/app/app.d/1236/vendor/bundle/ruby/3.0.0/bundler/gems/puma-fb10563f0209/lib/puma/cluster.rb:101:in `fork'", "/var/local/app/app.d/1236/vendor/bundle/ruby/3.0.0/bundler/gems/puma-fb10563f0209/lib/puma/cluster.rb:101:in `spawn_worker'", "/var/local/app/app.d/1236/vendor/bundle/ruby/3.0.0/bundler/gems/puma-fb10563f0209/lib/puma/cluster.rb:83:in `block in spawn_workers'", "/var/local/app/app.d/1236/vendor/bundle/ruby/3.0.0/bundler/gems/puma-fb10563f0209/lib/puma/cluster.rb:76:in `times'", "/var/local/app/app.d/1236/vendor/bundle/ruby/3.0.0/bundler/gems/puma-fb10563f0209/lib/puma/cluster.rb:76:in `spawn_workers'", "/var/local/app/app.d/1236/vendor/bundle/ruby/3.0.0/bundler/gems/puma-fb10563f0209/lib/puma/cluster.rb:165:in `check_workers'", "/var/local/app/app.d/1236/vendor/bundle/ruby/3.0.0/bundler/gems/puma-fb10563f0209/lib/puma/cluster.rb:439:in `run'", "/var/local/app/app.d/1236/vendor/bundle/ruby/3.0.0/bundler/gems/puma-fb10563f0209/lib/puma/launcher.rb:178:in `run'", "/var/local/app/app.d/1236/vendor/bundle/ruby/3.0.0/bundler/gems/puma-fb10563f0209/lib/puma/cli.rb:81:in `run'", "/var/local/app/app.d/1236/vendor/bundle/ruby/3.0.0/bundler/gems/puma-fb10563f0209/bin/puma-wild:25:in `<main>'"]
[159284] Could not find io-wait-0.2.1 in any of the sources
[159284] Early termination of worker

io-wait seems to be a descendent dependency of actionmailer / actionmailbox

When we run bundle open io-wait, the gem is there under app/app.d/1239/vendor.... If you also look at the backtrace log above, the error points to app/app.d/1236 but this folder got deleted, we're now at app/app.d/1239, as we can see from Gemfile in context: /var/local/app/app.d/1239/Gemfile as well.

We keep investigating but wanted to post what we found so far.

gingerlime · 2022-05-31T07:05:25Z

side-note: would you be happy with a PR to better log when worker fails? at the moment it only logs the first item from the backtrace, and not even the error itself.

dentarg · 2022-05-31T10:07:32Z

I think it makes sense to have better logging when this happens

gingerlime · 2022-06-01T14:23:16Z

@nateberkopec we found a workaround, and also managed to reproduce the issue hopefully.

The workaround for us was to install io-wait:0.2.1 globally using gem install io-wait:0.2.1. We're still not sure why the global gem interferes with the local one, and the local one gets installed and exists in the folders.

The repro can be found at https://github.com/gingerlime/puma-phased-restart-bundler-error

MSP-Greg · 2022-06-01T18:57:52Z

std-lib extension gems have been an issue for Bundler and also Puma.

Possibly the solution is to lock std-lib extension gems (used with Puma) to the version included with the Ruby used, and if the Ruby does not have the gem, install it locally as you suggested?

gingerlime · 2022-06-01T19:09:09Z

I'm not sure I fully understand, but obviously I'm not familiar with Bundler or Puma at an intimate level.

In particular why the problem only surfaces with phased-restart, after clearing one of the original folders. It doesn't happen when we load puma initially.

Did you get a chance to try out the repro? it's complaining about not being able to find rails-7.0.2.3 after a couple of phased-restarts (once the initial folder where puma was loaded gets scrapped). This seems very odd to me intuitively.

MSP-Greg · 2022-06-02T13:39:01Z

Did you get a chance to try out the repro?

No yet, but soon.

MSP-Greg · 2022-06-03T15:54:34Z

Ok, ran it, updating to use Puma master. First of all, has this worked with previous versions of Puma/Rails/Bundler?

Anyway, you might review info on phased-restart/SIGUSR1. A phased-restart cannot reload Puma, and your code is deleting the Puma files (calling delete_old_releases), as they exist in the folder that contains Puma when it's started. Phased-restart with prune_bundler will reload the app, but the main Puma process is not stopped or restarted.

Re the issue I referred to previously, think of running bundle exec. If Bundler uses an extension gem in its code, it may be required before the gems in the bundle are activated. If that extension gem is in the bundle and is a different release that one Bundler initially loaded, there are problems. As an example, Bundler was using the digest gem to generate an SHA1, and they wrote Ruby code to generate the SHA1, allowing the digest extension gem to be removed.

Note that one can delete old releases, just not the original one that started Puma. I.think.

gingerlime · 2022-06-03T17:16:24Z

Note that one can delete old releases, just not the original one that started Puma. I.think.

We definitely delete old releases, including the one that started puma and it works.

Unfortunately, the repro doesn't exactly have the same error with io-wait as we have on our environment, but I suspect it's related to using bundle config set deployment 'true'. If I skip this on the repro and just use bundle install then it seems fine. We also use bundle config set deployment 'true' when we deploy though. I don't quite understand what's the connection. I thought it was essentially to disallow changing the Gemfile. But it seems like without it, bundler might install gems globally? and with it, only locally? even if it installs locally, why does it fail with phased-restart? I don't know.

Perhaps @cjlarose can chime in? he worked on a similar problem with phased-restart and I kinda based my repro on his original one, albeit with Rails rather than just rack + some tweaks to bundler to more closely match what we do on our staging and live environments.

gingerlime · 2022-06-03T17:37:49Z

I just noticed that when we run bundle update rails it actually removes the io-wait dependency in Gemfile.lock (in rails 7.0.3, we were testing rails 7.0.2.3, maybe here?). So I guess this fixes the problem (????!!!????!)

I'm still very confused about the bundler behaviour here though. Especially when using bundle config set deployment 'true'.

MSP-Greg · 2022-06-03T18:33:28Z

Sorry, AFK. I'll look more this weekend. io/wait was added Jul 25, 2021, v5.40, in #6e4257fece, so it's been around for a while. I think deployment switches to vendor/bundle?

gingerlime · 2022-06-03T18:57:48Z

Thank you @MSP-Greg !

I was referring to the rails io-wait dependency rather than puma, but as far as I can tell there’s no explicit dependency in puma, just relying on stdlib, right?

MSP-Greg · 2022-06-03T20:13:22Z

there’s no explicit dependency in puma, just relying on stdlib, right?

Puma gemspec:

s.required_ruby_version = Gem::Requirement.new(">= 2.2")

There is no io-wait gem available for Ruby 2.2, as first release (0.1.0) was '>= 2.3.0'. So, we can't add an explicit dependency. Maybe next major release...

dentarg · 2022-06-06T15:47:07Z

I just noticed that when we run bundle update rails it actually removes the io-wait dependency in Gemfile.lock (in rails 7.0.3, we were testing rails 7.0.2.3, maybe here?)

Since rails v7.0.1, actionmailbox and actionmailer depend on net-imap, net-pop, net-smtp (rails/rails#44083 / rails/rails@cb44df7).

These all depend on net-protocol, from https://rubygems.org/gems/net-protocol/reverse_dependencies today:

net-smtp 0.3.1
net-imap 0.2.3
net-pop 0.1.1
net-ftp 0.1.3

net-protocol depended on io-wait until v0.1.3 (ruby/net-protocol@5f8bb52), released 2022-04-01, https://rubygems.org/gems/net-protocol

0.1.3 - April 01, 2022 (10 KB)
0.1.2 - October 21, 2021 (10.5 KB)

So when you upgraded rails from 7.0.2.3 to 7.0.3 io-wait was correctly removed from the bundle I think.

From https://rubygems.org/gems/rails/versions

7.0.3 - May 09, 2022 (6.5 KB)
7.0.2.4 - April 26, 2022 (6.5 KB)
7.0.2.3 - March 08, 2022 (6.5 KB)
7.0.2.2 - February 11, 2022 (6.5 KB)
7.0.2.1 - February 11, 2022 (6.5 KB)
7.0.2 - February 08, 2022 (6.5 KB)
7.0.1 - January 06, 2022 (6.5 KB)
7.0.0 - December 15, 2021 (6.5 KB)

I think one should restart Puma when applying dependencies changes, like upgrading Rails.

dentarg · 2022-06-06T16:10:28Z

So since Puma v5.4.0 (#2666) the Puma master process depend on io-wait. Ruby 3.0.2 ships with io-wait 0.1.0, but if you happen to have newer io-wait in your bundle, phased-restarts removing io-wait from the bundle wont work (as documented).

gingerlime · 2022-06-07T09:29:41Z

Ruby 3.0.2 ships with io-wait 0.1.0, but if you happen to have newer io-wait in your bundle, phased-restarts removing io-wait from the bundle wont work (as documented).

I'm not sure which part of the documentation explains this particular case? if io-wait is being added as a dependency to Puma, or Rails again, or another gem, then phased restarts can break if the system gem isn't matching from our experience. I wonder if there's a way to resolve or avoid this.

It's definitely a tricky question, and I still have very little understanding of bundler and puma, but I still think it's a question worth asking. At the very least also recommend how to use bundler when using phased restarts? (e.g. perhaps it's not safe to use bundle config set deployment 'true' and better to install the gems globally on the system?

dentarg · 2022-06-07T12:29:14Z

I'm not sure which part of the documentation explains this particular case?

What is documented is

Phased restarts cannot be used to upgrade any gems loaded by the Puma master process

Since Puma v5.4.0 this includes io-wait. Yes, I understand, this is really hard to know (I didn't until I looked this up for this issue).

If we had known about this edge-case, perhaps we would have been hesitant to make the change #2666. But it this issue also exist because Ruby is moving many parts of the standard library to gems... so I guess we theoretically could end up in this situation again down the road. I feel it is hard to get phased restarts 100% correct. I think would pick another deployment strategy if it was my app, or at least only use it when updating application code.

gingerlime · 2022-06-07T13:09:09Z

Thank you. I appreciate it.

I think would pick another deployment strategy if it was my app, or at least only use it when updating application code.

Yes, I'm starting to think the same. We're still running a simple app, so not ready to go to Kubernetes etc, yet most of the heroku-like services out there abstract a bit too much. Anything docker-based could be interesting, but docker-compose/swarm doesn't have a solid zero-downtime deploy option as far as I can tell. Any tips would be extremely valuable :)

MSP-Greg · 2022-06-07T14:08:05Z

One thing that may help with these issues would be to log all extensions loaded in the main Puma process on startup? Not sure how easy that would be, nor how long the list would be...

Also, we could vendor the methods being used from io-wait, but that might be a PITA given all the Ruby versions that are currently supported.

dentarg · 2022-06-07T14:28:35Z

One thing that may help with these issues would be to log all extensions loaded in the main Puma process on startup? Not sure how easy that would be, nor how long the list would be...

I was thinking that too, but also not sure exactly how to do that

Also, we could vendor the methods being used from io-wait, but that might be a PITA given all the Ruby versions that are currently supported.

Yeah, I don't think we should do that. It is hard enough already to maintain Puma, we should try to avoid making it even harder.

MSP-Greg · 2022-06-07T15:46:05Z

Yeah, I don't think we should do that. It is hard enough already to maintain Puma, we should try to avoid making it even harder.

Agreed. It would probably work almost all of the time, but sooner or later it would break, and that would be a mad dash to update it...

Re the 'loaded extensions', maybe something like the below?

We may be able to only use io-wait when nio4r is loaded, which for clustered servers, would remove the problem with io-wait. I.think. It might be messy.

Single mode:

* Listening on http://127.0.0.1:40001
* Loaded Extensions:
*     /mnt/c/GitHub/puma/vendor/bundle/ubuntu22/ruby/3.2.0+1/gems/nio4r-2.5.8/lib/nio4r_ext.so
*     /usr/local/lib/ruby/3.2.0+1/x86_64-linux/date_core.so
*     /usr/local/lib/ruby/3.2.0+1/x86_64-linux/enc/encdb.so
*     /usr/local/lib/ruby/3.2.0+1/x86_64-linux/enc/trans/transdb.so
*     /usr/local/lib/ruby/3.2.0+1/x86_64-linux/etc.so
*     /usr/local/lib/ruby/3.2.0+1/x86_64-linux/io/wait.so
*     /usr/local/lib/ruby/3.2.0+1/x86_64-linux/monitor.so
*     /usr/local/lib/ruby/3.2.0+1/x86_64-linux/pathname.so
*     /usr/local/lib/ruby/3.2.0+1/x86_64-linux/socket.so
*     /usr/local/lib/ruby/3.2.0+1/x86_64-linux/stringio.so
Use Ctrl-C to stop

Cluster mode:

[16449] * Listening on http://127.0.0.1:40001
[16449] * Loaded Extensions:
[16449] *     /usr/local/lib/ruby/3.2.0+1/x86_64-linux/date_core.so
[16449] *     /usr/local/lib/ruby/3.2.0+1/x86_64-linux/enc/encdb.so
[16449] *     /usr/local/lib/ruby/3.2.0+1/x86_64-linux/enc/trans/transdb.so
[16449] *     /usr/local/lib/ruby/3.2.0+1/x86_64-linux/etc.so
[16449] *     /usr/local/lib/ruby/3.2.0+1/x86_64-linux/io/wait.so
[16449] *     /usr/local/lib/ruby/3.2.0+1/x86_64-linux/monitor.so
[16449] *     /usr/local/lib/ruby/3.2.0+1/x86_64-linux/pathname.so
[16449] *     /usr/local/lib/ruby/3.2.0+1/x86_64-linux/socket.so
[16449] *     /usr/local/lib/ruby/3.2.0+1/x86_64-linux/stringio.so
[16449] Use Ctrl-C to stop

EDIT: Above were generated without io-wait in Gemfile.lock

MSP-Greg · 2022-06-07T16:57:19Z

I looked at Rails, and it also loads stringio, but it's not in any of the gemspecs. Ruby 2.7 uses v0.1.0, Ruby 3.0 & 3.1 use v3.0.1, and Ruby master is on v3.0.3.

So, it looks like Rails may have decided that 'gemified' std-lib extensions are not listed as gem dependencies, so they just use a require statement?

nateberkopec · 2022-07-05T22:45:10Z

So action item here is we need to explicitly mark our iowait dependency, right?

@MSP-Greg: re the 'loaded extensions', I'm in favor of adding that logging behind some kind of "verbose mode" switch (idk what switches we already have which would be appropriate).

MSP-Greg · 2022-07-06T00:36:26Z

@nateberkopec

re the 'loaded extensions', I'm in favor of adding that logging behind some kind of "verbose mode" switch

Ok. I'll look at the current switches, may add one.

For everyone, see PR #2903. In Ruby master, the io/wait methods being used in Puma have been moved into the native Ruby IO class. So, many years from now, when Ruby 3.2 is the Puma minimum required Ruby version...

dentarg · 2022-07-08T21:26:05Z

re the 'loaded extensions', I'm in favor of adding that logging behind some kind of "verbose mode" switch (idk what switches we already have which would be appropriate).

Behind environment variable PUMA_DEBUG perhaps?

MSP-Greg · 2022-07-08T21:57:17Z

That, or maybe PUMA_DEBUG_EXT or PUMA_LOADED_EXT?

MSP-Greg · 2022-07-08T23:25:28Z

Maybe it's time to have a debug ENV variable that can be a set of values that can be split? Would allow Puma to have several types of 'debug' logging, and one would just combine what options one wanted?

Not sure what everyone thinks of that, and what to name it...

dentarg · 2022-07-09T05:07:23Z

I vote for keeping it simple

dentarg · 2022-11-12T14:48:05Z

So action item here is we need to explicitly mark our iowait dependency, right?

How is that done? Add https://rubygems.org/gems/io-wait as runtime dependency in gemspec? But with Ruby 3.2 it wouldn't be needed, or even be a conflict?

I extracted the other actionable item here to its own issue: #3020

If we should change the gemspec, we should create a new issue about that. It could link to this issue for background. I'll close this issue now.

joker-777 changed the title ~~Bundler error prevents restarting puma after upgrading to rails 7~~ Bundler error prevents phased-restarting puma after upgrading to rails 7 Mar 17, 2022

nateberkopec added needs-repro restart labels Mar 19, 2022

gingerlime added a commit to gingerlime/puma-phased-restart-bundler-error that referenced this issue Jun 1, 2022

repro for puma/puma#2843

6f2eb7a

gingerlime mentioned this issue Jun 1, 2022

Extra log #2891

Merged

7 tasks

tonekk mentioned this issue Jun 8, 2022

prune_bundler does not work anymore with Ruby 2.7, Rails 6.1 #2893

Closed

silva96 mentioned this issue Nov 9, 2022

Ruby 3.2 will have native IO#wait_* methods, don't require io/wait #2903

Merged

7 tasks

dentarg mentioned this issue Nov 12, 2022

Log loaded extensions behind PUMA_DEBUG #3020

Closed

dentarg closed this as not planned Won't fix, can't repro, duplicate, stale Nov 12, 2022

dentarg mentioned this issue Dec 13, 2022

Phased restart issue with Ruby default Gem date #3033

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Bundler error prevents phased-restarting puma after upgrading to rails 7 #2843

Bundler error prevents phased-restarting puma after upgrading to rails 7 #2843

joker-777 commented Mar 17, 2022 •

edited

joker-777 commented Apr 6, 2022

nateberkopec commented Apr 9, 2022

gingerlime commented Apr 10, 2022 •

edited

nateberkopec commented Apr 11, 2022

gingerlime commented May 31, 2022 •

edited

gingerlime commented May 31, 2022

dentarg commented May 31, 2022

gingerlime commented Jun 1, 2022

MSP-Greg commented Jun 1, 2022

gingerlime commented Jun 1, 2022 •

edited

MSP-Greg commented Jun 2, 2022

MSP-Greg commented Jun 3, 2022

gingerlime commented Jun 3, 2022

gingerlime commented Jun 3, 2022 •

edited

MSP-Greg commented Jun 3, 2022 •

edited

gingerlime commented Jun 3, 2022

MSP-Greg commented Jun 3, 2022

dentarg commented Jun 6, 2022

dentarg commented Jun 6, 2022 •

edited

gingerlime commented Jun 7, 2022

dentarg commented Jun 7, 2022

gingerlime commented Jun 7, 2022

MSP-Greg commented Jun 7, 2022

dentarg commented Jun 7, 2022

MSP-Greg commented Jun 7, 2022 •

edited

MSP-Greg commented Jun 7, 2022 •

edited

nateberkopec commented Jul 5, 2022

MSP-Greg commented Jul 6, 2022

dentarg commented Jul 8, 2022

MSP-Greg commented Jul 8, 2022

MSP-Greg commented Jul 8, 2022

dentarg commented Jul 9, 2022

dentarg commented Nov 12, 2022

Bundler error prevents phased-restarting puma after upgrading to rails 7 #2843

Bundler error prevents phased-restarting puma after upgrading to rails 7 #2843

Comments

joker-777 commented Mar 17, 2022 • edited

joker-777 commented Apr 6, 2022

nateberkopec commented Apr 9, 2022

gingerlime commented Apr 10, 2022 • edited

nateberkopec commented Apr 11, 2022

gingerlime commented May 31, 2022 • edited

gingerlime commented May 31, 2022

dentarg commented May 31, 2022

gingerlime commented Jun 1, 2022

MSP-Greg commented Jun 1, 2022

gingerlime commented Jun 1, 2022 • edited

MSP-Greg commented Jun 2, 2022

MSP-Greg commented Jun 3, 2022

gingerlime commented Jun 3, 2022

gingerlime commented Jun 3, 2022 • edited

MSP-Greg commented Jun 3, 2022 • edited

gingerlime commented Jun 3, 2022

MSP-Greg commented Jun 3, 2022

dentarg commented Jun 6, 2022

dentarg commented Jun 6, 2022 • edited

gingerlime commented Jun 7, 2022

dentarg commented Jun 7, 2022

gingerlime commented Jun 7, 2022

MSP-Greg commented Jun 7, 2022

dentarg commented Jun 7, 2022

MSP-Greg commented Jun 7, 2022 • edited

MSP-Greg commented Jun 7, 2022 • edited

nateberkopec commented Jul 5, 2022

MSP-Greg commented Jul 6, 2022

dentarg commented Jul 8, 2022

MSP-Greg commented Jul 8, 2022

MSP-Greg commented Jul 8, 2022

dentarg commented Jul 9, 2022

dentarg commented Nov 12, 2022

joker-777 commented Mar 17, 2022 •

edited

gingerlime commented Apr 10, 2022 •

edited

gingerlime commented May 31, 2022 •

edited

gingerlime commented Jun 1, 2022 •

edited

gingerlime commented Jun 3, 2022 •

edited

MSP-Greg commented Jun 3, 2022 •

edited

dentarg commented Jun 6, 2022 •

edited

MSP-Greg commented Jun 7, 2022 •

edited

MSP-Greg commented Jun 7, 2022 •

edited