I'm using the puma application server, and it has a config file at config/puma.rb:
path = "/home/starkers/Documents/" + Rails.application.class.parent_name + "/tmp/puma/"
threads 0,20
environment "production"
daemonize true
bind "unix://" + path + "socket/puma.sock"
pidfile path + "pid/puma.pid"
state_path path + "pid/puma.state"
When running puma -C config/puma.rb to load this file and start the application server, everything works apart from the Rails.application.class.parent_name.
Can you think of anyway to get constants into the puma.rb file? Failing this, I suppose a workaround whcih gets the directory name of the root would work.
I'd like to use this attribute as well in the config,
Rails.root, but I need to get the Rails constant in! Do I need to use require?
You're going to need to load up your entire Rails app to get access to that object. You should be able to do this with a require 'config/environment' at the top of your puma.rb.
Related
My puma config:
path = Dir.pwd + "/tmp/puma/"
threads 0,20
environment "production"
daemonize true
drain_on_shutdown true
bind "unix://" + path + "socket/puma.sock"
pidfile path + "pid/puma.pid"
state_path path + "pid/puma.state"
My environments/production.rb
MyApp::Application.configure do
config.log_level = :debug
end
I start my server:
starkers#ubuntu:~/Desktop/myspp$ pumactl -F config/puma.rb start
=> Booting Puma
=> Rails 4.0.2 application starting in production on http://0.0.0.0:3000
=> Run `rails server -h` for more startup options
=> Ctrl-C to shutdown server
config.eager_load is set to nil. Please update your config/environments/*.rb files accordingly:
* development - set it to false
* test - set it to false (unless you use a tool that preloads your test environment)
* production - set it to true
Puma 2.8.2 starting...
* Min threads: 0, max threads: 16
* Environment: production
* Listening on tcp://0.0.0.0:3000
I browse about my app. And my log/production.log is blank. Not sure why?
Directory access is 0777 throughout my app.
No idea what is causing this. Really need logs (obviously). Happening locally and remotely so it's something to do with my configuration. However I'm not sure what configuration. Is there anything in puma/ubuntu/rails that could be causing this?
development.log works perfectly. I've copy pasted my development.rb to my production.rb file. Literally identical. Okay? Identical development.rb and production .rb And yet:
RAILS_ENV=development rails s
populates development.log
and
RAILS_ENV=production rails s
leaves production.log as empty as Kim Kardashian's head.
Set bind at the end of config file:
path = Dir.pwd + "/tmp/puma/"
threads 0,20
environment "production"
daemonize true
drain_on_shutdown true
pidfile path + "pid/puma.pid"
state_path path + "pid/puma.state"
bind "unix://" + path + "socket/puma.sock"
I used command pumactl -F config/puma.rb start to start server (i guess there is no difference, but anyway).
And i would recommend to use #{} for path:
pidfile "#{path}pid/puma.pid"
state_path "#{path}pid/puma.state"
bind "unix://#{path}socket/puma.sock"
but it's your choice.
Hope it helps (for me you config didn't work too).
you can also add Puma logs:
stdout_redirect "#{Dir.pwd}/log/puma.stdout.log", "#{Dir.pwd}/log/puma.stderr.log"
Add this line before bind.
If you want to add the output of the server to a log, the easiest way to do this is by telling your system to do exactly that. Running your server start command like:
pumactl -F config/puma.rb start >> log/development.log
Will append each line of output from your server to the development log. Though to make things easier to debug, you may want to give each server its own log such as log/puma.log. If you do, you may wish to rewrite the file from scratch every time you start the server instead of keeping a cumulative log, if that's the case just turn the >> into a > such as:
pumactl -F config/puma.rb start > log/puma.log
However, if you have your system set up to automatically restart the server if it fails, using > will overwrite the log for what might have caused the crash when the server restarts.
Similarly, you can get your production.log working by starting your rails server like:
RAILS_ENV=production rails s >> log/production.log
If you want to run your server in the background like you might in your production environment, you can add a & character to the end like:
pumactl -F config/puma.rb start > log/puma.log &
If you do this you'll probably want to store the process identifier so you can kill the server later as ^C doesn't work for background processes. To store the process id, create another empty file somewhere like lib/pids/puma.pid and then export the process id of that puma server to the empty file like:
pumactl -F config/puma.rb start > log/puma.log &
echo $! > lib/pids/puma.pid
You would then be able to kill the server with:
kill `cat lib/pids/puma.pid`
It is important to remember that even if you append the output of the server to your development.log file, it will not show up in the output of your development rails server. If you want a live view of your log for debugging, you can use the tailf command such as:
tailf log/puma.log
For more information on the command line interface, the Command Line Crash Course is a good resource.
I was following this guide it documents the puma.rb file that is stored inside the app's config directory.
The guide is a bit flakey, but here's what I assume the puma.rb file does. Instead of running crazy commands such as this to get puma running on a specified socket:
bundle exec puma -e production -b unix:///var/run/my_app.sock
You can just specify the port, pid, session and other parameters in the puma.rb file like this:
rails_env = ENV['RAILS_ENV'] || 'production'
threads 4,4
bind "/home/starkers/Documents/alpha/tmp/socket"
pidfile "/home/starkers/Documents/alpha/tmp/pid"
state_path "/home/starkers/Documents/alpha/tmp/state"
activate_control_app
And then you could cd into the app's root and run a simple command like
'puma'
and the parameters set in puma.rb would be followed. Unfortunately that doesn't seem to work for me.
At least, I ran puma inside the root of a tiny test app, and no .sock file appeared in
/home/starkers/Documents/alpha/tmp/sockets so does that mean it isn't working?
How do I get this working? I am on a local development machine, so could that cause this error somehow? Is there a parameter I need to pass in when running
puma ?
I was also stuck trying to find documentation on the config file for puma but I did find the all-in-one config.ru file useful. I've formatted it here for future reference:
# The directory to operate out of.
# The default is the current directory.
directory '/u/apps/lolcat'
# Load “path” as a rackup file.
# The default is “config.ru”.
rackup '/u/apps/lolcat/config.ru'
# Set the environment in which the rack's app will run. The value must be a string.
# The default is “development”.
environment 'production'
# Daemonize the server into the background. Highly suggest that
# this be combined with “pidfile” and “stdout_redirect”.
# The default is “false”.
daemonize
daemonize false
# Store the pid of the server in the file at “path”.
pidfile '/u/apps/lolcat/tmp/pids/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 '/u/apps/lolcat/tmp/pids/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 '/u/apps/lolcat/log/stdout', '/u/apps/lolcat/log/stderr'
stdout_redirect '/u/apps/lolcat/log/stdout', '/u/apps/lolcat/log/stderr', true
# Disable request logging.
# The default is “false”.
quiet
# 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
# Bind the server to “url”. “tcp://”, “unix://” and “ssl://” are the only
# accepted protocols.
# The default is “tcp://0.0.0.0:9292”.
bind 'tcp://0.0.0.0:9292'
bind 'unix:///var/run/puma.sock'
bind 'unix:///var/run/puma.sock?umask=0777'
bind 'ssl://127.0.0.1:9292?key=path_to_key&cert=path_to_cert'
# Listens on port 7001
# The default is 9292
port 7001
# Instead of “bind 'ssl://127.0.0.1:9292?key=path_to_key&cert=path_to_cert'” you
# can also use the “ssl_bind” option.
ssl_bind '127.0.0.1', '9292', { key: path_to_key, cert: path_to_cert }
# Code to run before doing a restart. This code should
# close log files, database connections, etc.
# This can be called multiple times to add code each time.
on_restart do
puts 'On restart...'
end
# Command to use to restart puma. This should be just how to
# load puma itself (ie. 'ruby -Ilib bin/puma'), not the arguments
# to puma, as those are the same as the original process.
restart_command '/u/app/lolcat/bin/restart_puma'
# === Cluster mode ===
# How many worker processes to run.
# The default is “0”.
workers 2
# Code to run when a worker boots to setup the process before booting
# the app.
# This can be called multiple times to add hooks.
on_worker_boot do
puts 'On worker boot...'
end
# === Puma control rack application ===
# Start the puma control rack application on “url”. This application can
# be communicated with to control the main server. Additionally, you can
# provide an authentication token, so all requests to the control server
# will need to include that token as a query parameter. This allows for
# simple authentication.
# Check out https://github.com/puma/puma/blob/master/lib/puma/app/status.rb
# to see what the app has available.
activate_control_app 'unix:///var/run/pumactl.sock'
activate_control_app 'unix:///var/run/pumactl.sock', { auth_token: '12345' }
activate_control_app 'unix:///var/run/pumactl.sock', { no_token: true }
Those settings would then go in a ruby file (e.g. config/puma.rb) and then as Starkers says, you can run it with
puma -C config/puma.rb
Update: The original answer is no longer correct for Puma versions since 2019: Puma added a fallback mechanism, so both locations are checked now. ( https://github.com/puma/puma/pull/1885)
Puma first looks for configuration at config/puma/<environment_name>.rb, and then falls back to config/puma.rb.
Outdated answer:
If there is an environment defined - which is the case in your example - the configuration file is read from config/puma/[environment].rb and not config/puma.rb.
Just move your config/puma.rb to config/puma/production.rb and it should work.
Read the Puma documentation for more details: Configuration file
This will work:
puma -C config/puma.rb
You need to tell puma where to find your rackup file you can do it by putting this in your config:
rackup DefaultRackup
It looks like a fix for this is merged into master: https://github.com/puma/puma/pull/271
I've got a line in config/unicorn.rb that looks like so:
working_directory "/SomePath/Web\ Development/Rails/learning"
but in the production environment, it needs to be a different path. I want do keep as much as I can under source control (haven't had to give up anything yet). Is there a way to set the working_directory based upon the environment?
How are you trying to access RAILS_ENV or RACK_ENV? It should be through "ENV" like...
ENV['RAILS_ENV']
... or ...
ENV['RACK_ENV']
One or the other should be available when you pass unicorn the "-E" flag (I can't remember which for sure, but I think it's RACK_ENV).
Using unicorn_rails makes the environment variables available.
You can access the rails environment with RAILS_ENV.
Our host does not allow us to modify the passenger config file (i.e. the apache config OR the vhosts file), but we'd like to run rails in dev mode. So we have to specify the environment (prod/dev/test) in one of the files that rails loads AS the application is restarted. Anyone know how to do this?
We've tried the following with no luck:
#environment.rb (before any other code is executed)
`RAILS_ENV=development` # using back ticks
ENV['RAILS_ENV'] = 'development' # assigning to a constant
RAILS_ENV='development' # as suggested by one of the answers, unfortunately does not work.
Setting it right at the top of environment.rb with:
RAILS_ENV = 'development'
should do it. It's possible that passenger overrides this, though.
If you don't have access to the passenger config but you do have access to your virtual hosts then you can also just force it in there with:
RailsEnv development
Why don't you change your production.rb config to match the settings found in development.rb?
In envriornment.rb you could add:
RAILS_ENV="production"
RAILS_ENV.freeze
That way when it tries to get reset later, it will fail.
I'm not sure what other ramifications this will have later or if it will permeate everywhere within rails.
Instead of setting ENV["RAILS_ENV"] in environment.rb, do so in boot.rb.
See here for details.
RAILS_ENV="production"
RAILS_ENV.freeze/ENV
That way when it tries to get reset later, it will fail.
I'm not sure what other ramifications this will have later or if it will permeate everywhere within rails.
I have a Rails application with a daemon that checks a mailbox for any new emails. I am using the Fetcher plugin for this task. The daemon file looks like this:
#!/usr/bin/env ruby
require File.dirname(__FILE__) + '/../config/environment.rb'
class MailFetcherDaemon < Daemon::Base
#config = YAML.load_file("#{RAILS_ROOT}/config/mail.yml")
#config = #config['production'].to_options
#sleep_time = #config.delete(:sleep_time) || 20
def self.start
puts "Starting MailFetcherDaemon"
# Add your own receiver object below
#fetcher = Fetcher.create({:receiver => MailProcessor}.merge(#config))
...
So I have it grab the new emails, parse them and create a resource from the parsed data. But when it tries to save the resource an exception is thrown. This is because the script is automatically assigned the development environment. So it is using my development database configuration instead of the production environment (which is the config that I want).
I have tried starting the script with:
rails-root$ RAILS_ENV=production; script/mail_fetcher start
but to no avail. It seems like when I load the environment.rb file it just defaults to the development environment and loads development.rb and the development database configuration from database.yml.
Thoughts? Suggestions?
Thanks
This is working in my app, the only difference I see is no semi-colon
RAILS_ENV=production script/mail_fetcher start
So when you say
RAILS_ENV=production; script/mail_fetcher start
do you mean
#!/bin/bash
export RAILS_ENV=production
cd /path/to/rails_root
./script/mail_fetcher start
You might try adding this to your script:
ENV['RAILS_ENV'] = "production"
Alternatively, it might work to add it to the command line.
#!/bin/bash
cd /path/to/rails_root
./script/mail_fetcher start RAILS_ENV=production