What is the best way to start thin in a rails application? - ruby-on-rails

You can start the thin server by one of the following ways:
thin start
rails s (if you have thin in the Gemfile)
Is there any difference on performance/compatibility between these two ways, or the rails s actually only calls thin start?

It seems that they are both functionally equivalent. However, adding thin to your Gemfile will only start thin automatically if you are using rails >= 3.2. Otherwise, you will have to start thin by passing rails server thin at the command line.
$ thin start
>> Using rack adapter
>> Thin web server (v1.5.1 codename Straight Razor)
>> Maximum connections set to 1024
>> Listening on 0.0.0.0:3000, CTRL+C to stop
Notice the difference between thin start and rails server if rails >= 3.2 or rails server thin
$ rails server thin
=> Booting Thin
=> Rails 3.2.13 application starting in development on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server
>> Thin web server (v1.5.1 codename Straight Razor)
>> Maximum connections set to 1024
>> Listening on 0.0.0.0:3000, CTRL+C to stop
It prints out more info about the rails environment. It seems that sticking to the rails server convention would be the wise thing to do. Although I haven't seen anything different between the two ways of starting thin, I would stick with the conventional rails server

Related

Rails running in development thinks it's in production mode

BIt of a weird one this.
rails s
=> Booting Thin
=> Rails 3.2.13 application starting in development on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server
Thin web server (v1.6.2 codename Doc Brown)
Maximum connections set to 1024
Listening on 0.0.0.0:3000, CTRL+C to stop
But when I call
puts Rails.env
in a controller, it says
production
In rails console it correctly says development
Rails.env
=> "development"
Any ideas.
I want to run in dev locally and production on my server. Particularly important as I'm testing functionality where it costs me money to run certain api calls and I have them faked if Rails.env.prodcution? is false.
Running rails 3.2.13

Specify which server a rails project will use

Just wondering if this can be done. You can specify you want a new rails project to use the postgresql server ike this:
rails new my-new-rails-project -d postgresql
and that takes care of the database yaml file.
Can an option be passed in here to specify puma as the development and production server so the relevant puma.rb configuration file is created?
Something like this:
rails new my-new-rails-project -d postgresql -s puma
By default Rails are using Webrick, but you can include different gem using Gemfile.
For example, you can use Thin (or puma, unicorn, whatever...) gem to your Gemfile and install it with bundler.
gem 'thin', group :development
When you start local server, rails will boot with custom webserver
rails server
=> Booting Thin
=> Rails 4.0.1 application starting in development on http://0.0.0.0:3000
=> Run `rails server -h` for more startup options
=> Ctrl-C to shutdown server
Thin web server (v1.6.1 codename Death Proof)
Maximum connections set to 1024
Listening on 0.0.0.0:3000, CTRL+C to stop
There is no option for server configuration in Rails. You can check using below command.
rails new --help

Thin webserver shuts down immediately after start (rails)

I am deploying a Rails application into production using Thin. Right after starting rails, Thin shuts down, the only ouput is 'Exiting':
$ bundle exec rails s -e production
=> Booting Thin
=> Rails 4.0.0 application starting in production on http://0.0.0.0:3000
=> Run `rails server -h` for more startup options
=> Ctrl-C to shutdown server
>> Thin web server (v1.5.1 codename Straight Razor)
>> Maximum connections set to 1024
>> Listening on 0.0.0.0:3000, CTRL+C to stop
Exiting
The same configuration / setup works in development. The same configuration works for production using WEBrick:
$ bundle exec rails s -e production
=> Booting WEBrick
=> Rails 4.0.0 application starting in production on http://0.0.0.0:3000
=> Run `rails server -h` for more startup options
=> Ctrl-C to shutdown server
[2013-07-19 17:59:07] INFO WEBrick 1.3.1
[2013-07-19 17:59:07] INFO ruby 2.0.0 (2013-06-27) [x86_64-linux]
[2013-07-19 17:59:07] INFO WEBrick::HTTPServer#start: pid=5231 port=3000
Surely it should be possible to receive some output on why it is shutting down from a web server rated for production use. However, I have not found out how.
Any ideas?
Turns out starting Thin in production mode made Rails eager load a module also using EventMachine, thus keeping the Thin code from being blocked after starting and immediately shutting down instead.

'rails server' starts thin twice, shuts both down. Cucumber still works

My rails application fails to start up in development mode. It appears to work in both production and test mode. Here is what I get when I run 'rails server':
Thin web server (v1.5.1 codename Straight Razor)
Maximum connections set to 1024
Listening on 0.0.0.0:51960, CTRL+C to stop
Booting Thin
Rails 3.2.11 application starting in development on http://0.0.0.0:3000
Call with -d to detach
Ctrl-C to shutdown server
Thin web server (v1.5.1 codename Straight Razor)
Maximum connections set to 1024
Listening on 0.0.0.0:3000, CTRL+C to stop
Exiting
One clue I've found is that thin seems to start before every call to rails. For example, here is what happens when I call rails console:
Thin web server (v1.5.1 codename Straight Razor)
Maximum connections set to 1024
Listening on 0.0.0.0:52262, CTRL+C to stop
Loading development environment (Rails 3.2.11)
This error has shown up on two different computers. The first (macbook) I simply cloned the github repository into a new folder and started it up from there, fixing things (how? Not sure). The second computer (iMac) did not respond to this.
I'm using ruby 1.9.3, rails 3.2, and thin 1.5.1.
More mysteriously, removing thin from my gemfile does nothing to fix the error. Rails still uses thin to start. I cannot find a direct reference to thin in the rest of my project.
Please excuse my relative ignorance of the internals of both rails and web servers. Any ideas on what might be causing this?
PS I am aware of this SO question and the solution there did not work for me.
I found out why. I was running the gem 'fake_braintree' in both development and test. It is meant to be run only in test. When it is run, it starts up a thin server which conflicts with the thin server I am wanting to run.

Webrick Fails to Run as Daemon, no Error Message

Running Ubuntu Server 10.04 with Rails 2.3.4 and Webrick 1.3.1; our rails app runs fine when called via script/server -e production, but trying to test it as a daemon by calling it with the -d flag produces the following output:
=> Booting WEBrick
=> Rails 2.3.4 application starting on http://0.0.0.0:3000
Nothing is produced in the logs, and other Rails applications will run detached without issue.
I assume You are running the Webrick in port 3000
>>$ sudo netstat -anp | grep 3000
tcp 0 0 0.0.0.0:3000 0.0.0.0:* LISTEN 8822/ruby
>>$ sudo kill -9 8822
I don't mean to contradict your choosing Webrick as a production server and maybe there is something I'm missing about why you are choosing Webrick, but have you considered other alternatives? I'd wager you already know all of this, but Webrick is the provided ruby server, and it is also the slowest ruby server choice.
Some of the most popular production server choices are:
Passenger
Thin
Mongrel
Unicorn
Glassfish
Passenger is likely the most popular choice for production now due to its easy configuration, speed, and features.
If there is a specific use case for Webrick that makes it better than any of the other server choices, I'd love to know.
You can add patch to enable error log here: https://github.com/rails/rails/blob/3-2-stable/activesupport/lib/active_support/core_ext/process/daemon.rb#L16
To
unless noclose
STDIN.reopen "/dev/null" # Free file descriptors and
STDOUT.reopen "/dev/null", "a" # point them somewhere sensible.
STDERR.reopen '/tmp/rails_daemon_err.log', 'a'
end
Now when you start rails server with -d, the error log will append to /tmp/rails_daemon.log.

Resources