The only difference I've noted is that rails server starts the server on port 3000, while rackup starts the server on port 9292.
Are there any other differences?
Are there use cases for one instead of the other?
rails server is the command for starting your server (usually WEBrick) and is in rails.
rackup is a command that comes with the rack middle and uses the settings in your config.ru and starts a server based off of those. This is a standard (it will work for other frameworks and rack-based applications) and is usually used in production servers.
One difference of note is that if you start a server with rails s then you will see the output in the terminal.
In my experience, in production, rackup is used by phusion passenger so you wouldn't want rails s in that situation.
As an aside, the port can be changed with both rails server and rackup using the -p flag.
Related
Some guides (example) recommend this to start one's webserver
bundle exec rails server puma
But I've always just started the server with puma directly
bundle exec puma
Does something special happening when firing up puma (or any other server) via rails server?
When you use rails s <server>, the server is launched from the Rails command and is aware of the Rails environment.
This makes possible, for example, to use any of the features and flags offered by the rails server command.
rails s --help
Usage: rails server [mongrel, thin, etc] [options]
-p, --port=port Runs Rails on the specified port.
Default: 3000
-b, --binding=ip Binds Rails to the specified ip.
Default: 0.0.0.0
-c, --config=file Use custom rackup configuration file
-d, --daemon Make server run as a Daemon.
-u, --debugger Enable ruby-debugging for the server.
-e, --environment=name Specifies the environment to run this server under (test/development/production).
Default: development
-P, --pid=pid Specifies the PID file.
Default: tmp/pids/server.pid
-h, --help Show this help message.
For instance, you can attach a debugger to the session passing --debugger or daemonize the server.
The second advantage is that you can version the Puma instance, since you will have to list the gem in the Gemfile. This is already true if you start it with bundle exec like you are doing.
Conversely, when you simply run $ puma (or $ bundle exec puma) you're not passing through the Rails system. Puma will try to find a rack bootstrap file and will use it (it works because Rails provides a config.ru script in the application root.
Generally speaking, there is no real difference if you don't need to pass specific options to the server. I like puma and I tend to use it in some projects even when on production we use Unicorn, thus running $ puma as a standalone command is handy because I don't need to add it to the Gemfile.
However, I would probably go with $ rails s puma if my entire stack uses Puma. This is also the command suggested in the documentation.
I am using private_pub gem for live chat in my rails 3.2 application and it is working perfectly on development mode but I am stuck at how to do it on production.
I am using apache2 in production. When I ran this command on server
RAILS_ENV=production bundle exec rackup private_pub.ru -s thin -E production
It starts the thin server but my app keeps on waiting for response from
http://www.example.com:9292/faye.js
It doesn't do anything. I am unable to connect with faye in prodution
Thanks for help in advance
Thin and Apache need to be set up running on different ports.
The default settings for both should work, but you should double
check. Ensure apache is running under port 80 and thin is using port
9292. These numbers should be visible when the servers start up.
In the end you should be able to access faye.js at
http://yoursite.com:9292/faye.js and your site at http://yoursite.com/
Source: https://stackoverflow.com/a/6667347/539075
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.
I am using following command for start the production server.
nohup ruby script/server webrick -e production &
My Rails applications start with port number in URL, like this one:
http://myapp.com:3000/
How to remove port no from the app URL? I think I need to install something like Passenger, If so anyone suggest me a good tutorial.
PS: My rails App hosted in http://dreamhost.com and I am using Rails 2.3r
In a production environment you probably want to use passenger instead of doing things by yourself.
"No port" for HTTP means port 80, so specify that with the -p 80 or --port=80:
nohup ruby script/server webrick -e production -p 80 &
You don't need Passenger, but using it can make things easier to manage for smaller apps and requires less babysitting.
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.