puma: IOError: stream closed from "@notify.close" when `close` is called from server.rb

We’re getting an error like this every few days in a small internal service app (running Padrino, deployed to Heroku) with low amounts of traffic:

IOError in at_exit
IOError: stream closed

[GEM_ROOT]/gems/puma-3.8.2/lib/puma/server.rb:393 :in `close`
 [GEM_ROOT]/gems/puma-3.8.2/lib/puma/server.rb:393 :in `ensure in handle_servers`
 [GEM_ROOT]/gems/puma-3.8.2/lib/puma/server.rb:396 :in `handle_servers`
 [GEM_ROOT]/gems/puma-3.8.2/lib/puma/server.rb:325 :in `block in run`

Line 393 being:

[GEM_ROOT]/gems/puma-3.8.2/lib/puma/server.rb:393:in `close'
391       ensure
392         @check.close
>>>393         @notify.close
394 
395         if @status != :restart and @own_binder

I haven’t dug into this, but apparently @notify is some IOStream that is already closed when we’re trying to close it, on server shutdown.

I would guess Puma could check if it’s closed already to fix that error, but that’s kind of sweeping it under the rug. Any ideas what the issue could be? Something we might be doing wrong on our end?

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Reactions: 4
  • Comments: 19 (11 by maintainers)

Commits related to this issue

Most upvoted comments

Just letting you know that we are seeing the same problem with puma 3.8.2 & Rails 5.0.2. I don’t think we have anything special in the application that would cause it but you’ll never know.

We also have quite low amounts of traffic (the application is still in development).

Puma 3.10.0 has been released and includes this fix.

The hooks for the stopgap gem have not yet been added in a Puma release. They are only in master branch for now.

this seems to be a bug I’ve described in #1302. It’s a Ruby issue, I’ve reported it and you can monitor it being backported here: https://bugs.ruby-lang.org/issues/13632