Error While Starting Puma Server with Workers

Error while starting Puma server with workers

To cite from the Puma README:

Because of various platforms not being implement certain things, the following differences occur when Puma is used on different platforms:

• JRuby, Windows: server sockets are not seamless on restart, they must be closed and reopened. These platforms have no way to pass descriptors into a new process that is exposed to ruby
• JRuby, Windows: cluster mode is not supported due to a lack of fork(2)
• Windows: daemon mode is not supported due to a lack of fork(2)

As it clearly states, cluster mode (i.e. running a single puma instance with multiple workers) and daemon mode (detaching from the shell after starting) are not supported on Windows.

You should either use a differt OS (e.g. Linux) or use Puma in single-worker mode. You could manually start multiple Puma instance on different ports and loadbalance between them though, even on Windows. You just need a frontend loadbalancer for that and it isn't as seamless as the native cluster mode builtin to Puma.

Rails - Puma randomly failed to start a worker

Posting the answer here for anyone who has not figured this out yet.

heroku config:set "BUNDLE_DISABLE_EXEC_LOAD"="true"

see this thread: github puma issue

Rails & Puma Server Start Error

Puma is complaining that /Users/Paradise/Documents/Dev/salon-spa-pass/AdminInterface/shared/log/puma.std‌​out.log is not found. On a unix/linux/Mac OS X system, that could mean that the process (or its user) doesn't have permissions to that file.

Check that the file does exist and that the permissions are set properly. If the file does not exist, you can do something like this on Unix systems to create the folders in the path and a blank file:

mkdir -p /Users/Paradise/Documents/Dev/salon-spa-pass/AdminInterface/shared/log/ && touch /Users/Paradise/Documents/Dev/salon-spa-pass/AdminInterface/shared/log/puma.std‌​out.log

This will ensure that the file is created properly. Be sure to verify your file permissions again after you do this.

Puma starts but does not create the processes

The problem apparently was with the puma socket, my nginx was not be able to bind it.

upstream myapp_puma {
 server unix:///home/ubuntu/vaypol-ecommerce/shared/sockets/puma.sock fail_timeout=0;
}

Why puma webserver fails in development with multiple requests at a time?

If you read my question carefully, you will find several clues pointing to a concurrency problem.

threads_count = 2

If the frontend requests multiple requests at a time, not all requests are processed properly

If I set the thread_count to 1, there's no error

At the time, I didn't see those clues and didn't know what was going on ;). Often you can't see the forest for the trees.

@Myst could see the clues and pointed me in the right direction.

I'm using great hanami-api for my API and the controllers are hanami-controllers (1.3). Here's a code-snippet, which includes the concurrency-bug:

class MyAPI < Hanami::API
  scope "api" do
    scope "graphql" do
      post "endpoint", to: App["controllers.graphql.endpoint"]
    end
  end
end

Then I found this useful text in the docs:

An Action is mutable. When used without Hanami::Router, be sure to instantiate an action for each request. The same advice applies when using Hanami::Router but NOT routing to mycontroller#myaction but instead routing direct to a class.

Meanwhile there is already hanami-controller 2.x, and they are thread-safe by design.

But in my case I had to fix my code to:

class MyAPI < Hanami::API
  scope "api" do
    scope "graphql" do
      post "endpoint",  to: ->(env) { App["controllers.graphql.endpoint"].call(env) }
    end
  end
end

error with puma in local server

Not positive this will solve your problem. I usually run the app locally using foreman. The puma documentation for rails suggests starting your local server like this:

rails s Puma

For what it's worth.

What does Early termination of worker puma log mean and why is it happening?

Ok so this took a lot of debugging and going down a lot of different rabbit holes. The problem was very painfully simple. I created a class which I misspelled and called, GetLitsingsResponse. After changing the class back to GetListingsResponse Puma works just fine in my remote AWS Elastic beanstalk environment. It's very strange out locally on my Mac OS Puma had no problem. But in the 64bit Amazon Linux 2018.03 v2.11.4 running Ruby 2.6 (Puma) platform Puma would not function normally.

Puma Early termination of worker investigation difficult

Unexpected!

pumactl and having a control-url helped but a friend of mine suggested the best idea that I only wish was more obvious,

are you throwing the error on a different server?

I ran gem install thin and RAILS_ENV=production thin start finally showed me the error I was looking for!

As it turns out, I should not have been using non-public methods like add_template_helper as ActionMailer::Base may not always get all the methods of ActionController::Base. I didn't see this error in development because Rails does not eagerly load all of your classes.

Starting rails server as deamon doesn't trigger worker cluster

According to the Puma docs, it's recommended that you start with bundle exec puma.

You can then start a cluster like this: puma -t 8:32 -w 3. Where -t is the min:max number of threads and -w is the number of workers.

---

Related Topics