Why must I restart Puma twice in Ubuntu for it to work?
# uname -a
Linux myapp 3.11.0-12-generic #19-Ubuntu SMP Wed Oct 9 16:20:46 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
# pumactl -v
2.6.0
# pumactl -S /home/myapp/tmp/puma.state restart --config /home/myapp/config/puma.rb
Command restart sent success
[...that's not working, Puma is still running...]
# pumactl -S /home/myapp/tmp/puma.state restart --config /home/myapp/config/puma.rb
[9703] Puma starting in cluster mode...
[9703] * Version 2.6.0, codename: Pantsuit Party
[9703] * Min threads: 0, max threads: 16
[9703] * Environment: production
[9703] * Process workers: 2
[9703] * Phased restart available
[9703] * Listening on unix:///home/myapp/tmp/puma.sock
[9703] * Daemonizing...
[...ok now it worked...]
I wouldn't trust this pumactl script. Just use kill -SIGUSR2 <pid> as recommended in the puma documentation itself : https://github.com/puma/puma.
Related
I run this command to start my server
rails s -b 10.x.x.x
then I got this error
[1013] * Puma version: 5.2.2 (ruby 2.6.3-p62) ("Fettisdagsbulle")
[1013] * Min threads: 2
[1013] * Max threads: 2
[1013] * Environment: development
[1013] * Master PID: 1013
[1013] * Workers: 1
[1013] * Restarts: (✔) hot (✖) phased
[1013] * Preloading application
Exiting
Address already in use - bind(2) for "10.x.x.x" port 3000 (Errno::EADDRINUSE)
How do I stop this current running server 10.x.x.x:3000?
There are several utilities to get the PID of a proccess listening on a port.
lsof -i :3000
Will get you the PID and then you can kill it with kill [PID] or force it with kill -9 [PID]
When I lanch the command /home/centos/.rvm/rubies/ruby-3.0.0/bin/bundle exec puma -C /home/centos/app/config/puma.rb in the app folder I get no error :
[145103] Puma starting in cluster mode...
[145103] * Puma version: 5.2.1 (ruby 3.0.0-p0) ("Fettisdagsbulle")
[145103] * Min threads: 1
[145103] * Max threads: 5
[145103] * Environment: production
[145103] * Master PID: 145103
[145103] * Workers: 1
[145103] * Restarts: (✔) hot (✔) phased
[145103] * Listening on unix:///home/centos/app/tmp/sockets/puma.sock
But when I try to start Puma as service service puma start && service puma status I get :
● puma.service - Puma HTTP Server
Loaded: loaded (/etc/systemd/system/puma.service; enabled; vendor preset: disabled)
Active: activating (auto-restart) (Result: exit-code) since Mon 2021-02-15 17:37:24 UTC; 938ms ago
Process: 145289 ExecStart=/home/centos/.rvm/rubies/ruby-3.0.0/bin/bundle exec puma -C /home/centos/app/config/puma.rb (code=exited, st>
Main PID: 145289 (code=exited, status=203/EXEC)
Feb 15 17:37:24 centos-s systemd[1]: puma.service: Main process exited, code=exited, status=203/EXEC
Feb 15 17:37:24 centos-s systemd[1]: puma.service: Failed with result 'exit-code'.
I don't understand why ?
Problem solved, just a too much parenthesis in the config/puma.rb
I want to start the rails server in production mode as a deamon running a worker cluster. When I start my rails program everything works as expected.
rails s -e production -b 0.0.0.0
=> Booting Puma
=> Rails 5.0.0.1 application starting in production on http://0.0.0.0:3000
=> Run `rails server -h` for more startup options
[12340] Puma starting in cluster mode...
[12340] * Version 3.4.0 (ruby 2.3.0-p0), codename: Owl Bowl Brawl
[12340] * Min threads: 5, max threads: 5
[12340] * Environment: production
[12340] * Process workers: 3
[12340] * Preloading application
[12340] * Listening on tcp://0.0.0.0:3000
[12340] Use Ctrl-C to stop
[12340] - Worker 0 (pid: 12347) booted, phase: 0
[12340] - Worker 1 (pid: 12349) booted, phase: 0
[12340] - Worker 2 (pid: 12353) booted, phase: 0
however when I add the -d rails starts in single mode, confirmed by checking running processes
rails s -e production -b 0.0.0.0 -d
=> Booting Puma
=> Rails 5.0.0.1 application starting in production on http://0.0.0.0:3000
=> Run `rails server -h` for more startup options
checking running processes confirms only one instance is running, not the clustered mode expected.
So, how do I correctly launch with workers as a deamon process?
Any help is much appreciated.
NOTE: I am also running puma_worker_killer for rolling restarts in case that helps.
rails (5.0.0.1)
puma (3.4.0)
puma_worker_killer (0.1.0)
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.
I try run my puma application server with the following command
RAILS_ENV=production puma -C config/puma.rb -e production -d
and then i see that everthing is going fine..
production [3111] Puma starting in cluster mode... [3111] * Version
3.12.0 (ruby 2.2.4-p230), codename: Llamas in Pajamas [3111] * Min threads: 1, max threads: 6 [3111] * Environment: production [3111] *
Process workers: 2 [3111] * Phased restart available [3111] *
Listening on
unix:///home/joaquin/Documents/ecommerce/vaypol-ecommerce/shared/sockets/puma.sock
[3111] * Daemonizing...
but at real the processes never startup if i try to check with ps aux | grep puma
so my config/puma.rb
# Change to match your CPU core count
workers 2
# Min and Max threads per worker
threads 1, 6
daemonize true
app_dir = File.expand_path("../..", __FILE__)
shared_dir = "#{app_dir}/shared"
# Default to production
rails_env = ENV['RAILS_ENV'] || "production"
environment rails_env
# Set up socket location
bind "unix://#{shared_dir}/sockets/puma.sock"
# Logging
stdout_redirect "#{shared_dir}/log/puma.stdout.log", "#{shared_dir}/log/puma.stderr.log", true
# Set master PID and state locations
pidfile "#{shared_dir}/pids/puma.pid"
state_path "#{shared_dir}/pids/puma.state"
activate_control_app
on_worker_boot do
require "active_record"
ActiveRecord::Base.connection.disconnect! rescue ActiveRecord::ConnectionNotEstablished
ActiveRecord::Base.establish_connection(YAML.load_file("#{app_dir}/config/database.yml")[rails_env])
What i missing up? Thanks at advance
Puma worker processes are forked from the original, parent, process, which is a ruby process.
Consider testing for processes named ruby rather than puma... i.e. (using your approach):
ps aux | grep ruby
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;
}
please be sure that these fold in shared , "log \ pids \ sockets", who will be used by puma. if these fold is not found, please mkdir to create them
I would like to run one and the same project twice on the same server. So I defined two environments alpha and beta for this purpose.
alpha should run on port 3000
beta should run on port 4000
Then I try to start the server twice:
$ ruby bin/rails server -b 0.0.0.0 -p 3000 -e alpha --pid tmp/pids/server-alpha.pid
$ ruby bin/rails server -b 0.0.0.0 -p 4000 -e beta --pid tmp/pids/server-beta.pid
Unfortunately one of those servers (the second to start) stops when it recognizes, that there is another instance.
Environment alpha starts:
=> Booting Puma
=> Rails 5.0.0.1 application starting in alpha on http://0.0.0.0:3000
=> Run `rails server -h` for more startup options
Puma starting in single mode...
* Version 3.6.0 (ruby 2.3.1-p112), codename: Sleepy Sunday Serenity
* Min threads: 5, max threads: 5
* Environment: alpha
* Listening on tcp://0.0.0.0:3000
Use Ctrl-C to stop
Environment beta starts:
=> Booting Puma
=> Rails 5.0.0.1 application starting in beta on http://0.0.0.0:4000
=> Run `rails server -h` for more startup options
Puma starting in single mode...
* Version 3.6.0 (ruby 2.3.1-p112), codename: Sleepy Sunday Serenity
* Min threads: 5, max threads: 5
* Environment: beta
* Listening on tcp://0.0.0.0:4000
Use Ctrl-C to stop
Environment alpha restarts (don't know why!):
* Restarting...
=> Booting Puma
=> Rails 5.0.0.1 application starting in alpha on http://0.0.0.0:3000
=> Run `rails server -h` for more startup options
A server is already running. Check tmp/pids/server-alpha.pid.
Exiting
Obviously the pid file still exists. But how can I avoid a restart of the server when I start another one? How can I tell rails to delete the pidfile on restart? Or how else could I handle this problem?
You probable have plugin :tmp_restart in your config/puma.rb. Everytime tmp/restart.txt is touched (which is everytime a server starts), the other server restarts.
Just comment the line and it works (you won't be able to restart your rails server by touching tmp/restart.txt anymore).
I'm not sure this will work but try using = after --pid like this
$ ruby bin/rails server -b 0.0.0.0 -p 3000 -e alpha --pid=tmp/pids/server-alpha.pid
$ ruby bin/rails server -b 0.0.0.0 -p 4000 -e beta --pid=tmp/pids/server-beta.pid