Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 07:42

    nateberkopec on v3.12.2

    (compare)

  • 07:42

    nateberkopec on 3.12.2

    Merge pull request from GHSA-7x… 4.3.1 and 4.2.1 release notes 3.12.2 (compare)

  • 07:36

    nateberkopec on v4.3.1

    (compare)

  • 07:35

    nateberkopec on 4.3.1

    Merge pull request from GHSA-7x… 4.3.1 and 4.2.1 release notes 4.3.1 (compare)

  • 07:33

    nateberkopec on master

    4.3.1 (compare)

  • 07:31

    nateberkopec on master

    4.3.1 and 4.2.1 release notes (compare)

  • 07:19

    nateberkopec on master

    Merge pull request from GHSA-7x… (compare)

  • Dec 04 21:04
    tkishel commented #2081
  • Dec 04 19:37
    tkishel commented #2081
  • Dec 04 19:37
    tkishel commented #2083
  • Dec 04 19:37
    tkishel edited #2083
  • Dec 04 19:36
    tkishel edited #2083
  • Dec 04 19:36
    tkishel edited #2083
  • Dec 04 19:36
    tkishel edited #2083
  • Dec 04 19:36
    tkishel edited #2083
  • Dec 04 19:36
    tkishel opened #2083
  • Dec 04 17:59
    tkishel commented #2081
  • Dec 04 17:53
    tkishel commented #2081
  • Dec 04 17:07
    tkishel commented #2081
  • Dec 04 11:26
    ayufan synchronize #2079
Blane Dabney
@raelik
?
Jonathan Boler
@jboler_gitlab
Does anyone run puma on jRuby using JVM server mode?
As far as I can tell puma defaults to running in JVM client mode and I can't find anything online about running it in server mode
Something like jruby --server $(which puma)
Jonathan Boler
@jboler_gitlab
After further research it looks like everything on 64bit is run in server mode these days
David Blewett
@davidblewett
I'm having trouble configuring Puma to accept connections from rust client code (using the rustls crate). No matter what I try, I end up with: #<Puma::MiniSSL::SSLError: OpenSSL error: error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher - 336109761>
Blane Dabney
@raelik
I believe this is a long-standing issue: puma/puma#1339
most folks resort to using a separate reverse proxy to handle SSL
David Blewett
@davidblewett
Blerg.
Blane Dabney
@raelik
Though, it might have something to do with SNI
if your Puma SSL works otherwise, but not when connecting with Rust, that may be the issue
David Blewett
@davidblewett
hmm; I turned SNI off in the rust client request and it still fails
I think it might be something to do with the signature_algorithms in the request
Blane Dabney
@raelik
that's possible too
Tomas Ruzicka
@LeZuse
Anybody here has any experience with debugging timed out workers in puma on heroku?
It might not be an issue with puma itself, but it is kinda difficult to dig more information from the runtime to repro the case
Essentially from time to time a worker gets stuck and times out the internal ping check timeout:
955422512366379010    2018-07-16T07:55:00    2018-07-16T07:55:00Z    47022513    pb-com    50.17.80.51    Local7    Info    app/web.2    [3] ! Terminating timed out worker: 14459
955422516652969998    2018-07-16T07:55:01    2018-07-16T07:55:01Z    47022513    pb-com    54.92.176.105    Local7    Info    app/web.2    I, [2018-07-16T07:55:01.116331 #14500]  INFO -- : Installing Puma worker loop.
955422516787187716    2018-07-16T07:55:01    2018-07-16T07:55:01Z    47022513    pb-com    54.92.176.105    Local7    Info    app/web.2    [3] - Worker 0 (pid: 14500) booted, phase: 0
We have mitigated the issue a little bit by setting a lower worker_timeout so that the check is more frequent, but that doesn't help us solve the root cause :(
Tomas Ruzicka
@LeZuse
We have also tried changing the config to puma single mode with more threads. We're seeing weird restart problems with that config.
When we try to restart the stuck dyno with heroku ps:restart it times out even the restart phase and Heroku issues SIGKILL:
Sep 12 10:27:23 pb-com heroku/web.3: Stopping all processes with SIGTERM 
Sep 12 10:27:53 pb-com heroku/web.3:  Error R12 (Exit timeout) -> At least one process failed to exit within 30 seconds of SIGTERM 
Sep 12 10:27:53 pb-com heroku/web.3:  Stopping remaining processes with SIGKILL 
Sep 12 10:27:53 pb-com heroku/web.3:  Process exited with status 137
SleepySecurityNinja
@SleepySecNinja_twitter
Hello. I'm curious if there is any specific security guidance on configuring puma?
Harm de Wit
@harmdewit
Hi, does anyone know when the next release will be? I'm waiting for an already merged PR to be released, last release was in July :sweat_smile:.
Cory Christensen
@Cory-Christensen
I would also like to know when the next release will be...I'm waiting for @harmdewit 's PR :)
Jules Ivanic
@guizmaii

Hello everyone,

I’m moving my Ruby MRI Rails app to JRuby and I’m worried about multi threading.

I used to use the Unicorn server which is a multi-processes server and I’m moving to JRuby and Puma (multi-threaded).

I’m looking, thanks to VisualVM, how the threads behave when I’m pushing several HTTP calls to the app and I see a lot of thread doing nothing.

How can I check that calls are correctly dispatched to threads ?
Here’s a screenshot of visualVM: https://www.dropbox.com/s/w43paa57m5jf8l3/Screenshot%202018-11-14%2015.18.55.png?dl=0

David Hollinger III
@dhollinger

Anyone here that can help me with puma not starting with a Sinatra app?

config/puma.rb

workers Integer(ENV['WEB_CONCURRENCY'] || 2)
threads_count = Integer(ENV['THREAD_COUNT'] || 5)
threads threads_count, threads_count

rackup      DefaultRackup
port        ENV['PORT']     || 3000
environment ENV['RACK_ENV'] || 'development'

Error message

$ bundle exec puma -C config/puma.rb
bundler: failed to load command: puma (/home/dhollinger/.asdf/installs/ruby/2.5.1/bin/puma)
NoMethodError: undefined method `workers' for main:Object
  /home/dhollinger/workspace/ruby/puppet_webhook/config/puma.rb:1:in `<top (required)>'
  /home/dhollinger/.asdf/installs/ruby/2.5.1/lib/ruby/gems/2.5.0/gems/puma-3.12.0/lib/puma/cli.rb:4:in `require'
  /home/dhollinger/.asdf/installs/ruby/2.5.1/lib/ruby/gems/2.5.0/gems/puma-3.12.0/lib/puma/cli.rb:4:in `<top (required)>'
  /home/dhollinger/.asdf/installs/ruby/2.5.1/lib/ruby/gems/2.5.0/gems/puma-3.12.0/bin/puma:6:in `require'
  /home/dhollinger/.asdf/installs/ruby/2.5.1/lib/ruby/gems/2.5.0/gems/puma-3.12.0/bin/puma:6:in `<top (required)>'
  /home/dhollinger/.asdf/installs/ruby/2.5.1/bin/puma:23:in `load'
  /home/dhollinger/.asdf/installs/ruby/2.5.1/bin/puma:23:in `<top (required)>'
kelly
@kellyprankin
Can anyone assist me with dealing with this?
kelly
@kellyprankin
Ok, so the temporary solution was to use a different version of the puma gem
kelly
@kellyprankin
What is the default directory for puma request errors?
*for logs in regard to this
LemonAndroid
@LemonAndroid
Hey, I'm having a problem with Thread.current variables being nil in the model, despite being initialized by Rails initializers. The gem in question is PublicActivity and I'm running Rails 6. I tried before_fork and on_worker_boot, but my presumption is, that Rails 6 does some threading on top of whatever server it is running on. Is that possible?
Alexander Fedulin
@jughead
worker is a process, it spawns threads. That’s why setting values in before_fore/on_worker_boot gives you nils in requests
Olle Jonsson
@olleolleolle
I'm getting the hang of writing tests for Puma, it's a bit like writing tests for Python. Very concrete.
LemonAndroid
@LemonAndroid
Ben Dean
@b-dean

I have a rails app (written by an outside company) running in Puma 3.11.4 on Ruby 2.2 (I know, sorry) and am running into all sorts of errors that I think have already been fixed in newer versions. As part of figuring out what's going on sorting out TLS problems and 100% CPU puma, our vendor tells us that it is "best practice" to not have Puma handle TLS but instead have nginx in front.

currently we have (more or less):
puma (in docker container) <---TLS port--- AWS Application Load Balancer <---TLS port------ some browser

and the vendor says that the well established best practice is:
puma (in docker container) <---TCP port--- nginx <----TLS port---- AWS Application Load Balancer <---TLS port------ some browser

because "puma isn't meant to handle TLS"

is that correct at all? I can't find anything to support it with some rudimentary searching. Also having two proxies seems like we're just asking for trouble.

I'm also just trying to update their code to use newer Puma and newer Ruby where I suspect those TLS issues will be fixed (at least from reading the CHANGELOG.md)

Blane Dabney
@raelik
Yes, it's pretty standard practice for most web applications these days to allow your reverse proxy (typically nginx) to handle TLS
There's other reasons to use a reverse proxy in front of your Rails app as well
e.g. X-Accel-Redirect and send_file for having nginx handle large files directly
Ben Dean
@b-dean
I'm more wondering about it being best practice to not use Puma's TLS because it's "not meant for TLS" or some such thing. We have the Amazon ALB which is providing a proxy. We had been having Puma do TLS too so we didn't have unencrypted network traffic between the docker container running Puma and the load balancer (which our security guy says is required by PCI)
Seems like most of the recent Puma changes have been to fix something or other related to TLS. Seems odd that they'd spend all that effort if they really only want people to use nginx
Blane Dabney
@raelik
You CAN use Puma's TLS support, it's just not considered best practices. In general, it's always been best practice to put any Rails webserver (unicorn, thin, puma, etc) behind some kind of reverse proxy, TLS or no.
Primarily, this is due to Ruby's lack of native threads and the necessity to run multiple processes to scale properly.
Jae Lee
@jaequery_gitlab
hi, i randomly get this error : "An unhandled lowlevel error occurred. The application logs may have details." , after I googled it, it seem to point to Puma requiring "SECRET_BASE_KEY" environmental being set. i can't seem to find any info on this, what's the value supposed to be?
(alpha numeric , max length, etc )
im using Sinatra btw
not Rails so i couldn't find any more info on it
Blane Dabney
@raelik
That's not a puma thing
Not that I can see. Maybe a gem or some middleware looking for it?
Quick question: Is there a best practice for how to handle connection queueing? I have a raw Puma/Rack app that sits behind an nginx load balancer, and currently, all of the queueing happens in puma. However, for reasons unrelated to queueing, I'm about to put a local nginx on the app servers, between the load balancer nginx and puma itself (it's for a flat-file caching setup). Should I just keep letting Puma queue, or should I disable that and configure the local nginx to handle the connection queueing? If so, are there any guidelines or pitfalls I should be aware of?