How to Restart Rails from Within Rails

How to restart Rails from within Rails?

Ok I found a fix... I changed how I start rails to:

mongrel_rails start -d

and now the following action will do it:

def restart
  fork { exec "mongrel_rails restart" }
  redirect_to "/server_maintenance"
end

As a caveat, the redirect_to will cause a failed load because the server will be down... however a reload after a pause will show that the restart was successful. This could be fixed by changing the restart to be done with AJAX, followed by a javascript reload... but I will leave that as an exercise to the reader.

How to stop (and restart) the Rails Server?

Press Ctrl+C

When you start the server it mentions this in the startup text.

When do I need to restart server in Rails?

2021 UPDATE:

Since this answer is my most visible answer on StackOverflow and it's quite old, I thought it was about time to update it to go a little more in-depth. It's original info is not incorrect, but it's a bit too generic, and I feel I can explain it better with the knowledge I have now. The original answer is preserved below.

The way Rails works vs plain ruby is that it basically requires your files on-the-fly without you needing to add requires on the top of the file. There is nowadays a good relatively in-depth page about it on the official Rails guides here.

Starting on Rails 6, they introduced a new loader to manage the logic for automatically loading the source files, off-loading that work to a gem called zeitwerk. There is also a page on the Rails guides that explains how the new loader works.

The basic idea is something like this:

1. Rails runs a bunch of config files (environment.rb, application.rb, boot.rb, the respective environments/<environment>.rb, config/routes.rb, initializers, etc). All the files ran in this starting phase are in the config directory, so if the changed file is inside the config directory, it probably will need a Rails restart.

2. Rails then starts watching all the files under each of it's autoload_paths (by default each dir inside app) to check when any of them change. It also specifically watches for changes on the config/routes.rb file.

3. Now armed with a nice route configuration, Rails knows to which paths to respond and with which controllers. Once you hit one of the configured routes, Rails will run your controller action.

4. Whenever ruby sees a constant that it doesn't recognize, it calls the method const_missing. Rails overrides this method to get the name of your constant and use it to search for a file with the same name inside each directory of the autoload_paths.

5. When it finds the file it then requires it on-the-fly, with the assumption that it will define the constant that triggered the const_missing, and then the code goes on.

6. Next time the same constant is used, it will now be defined, so it won't even reach the const_missing method.

7. Last but not least, IF the config cache_classes is set to false (the default on the development environment), then whenever Rails catches a change in one of the files it's watching, it will unset the constant associated with the file (that it knows from the name of the file).

So whenever you need to change anything that is loaded in that step 1, with the exception of the specially treated config/routes.rb, you need to restart Rails. Anything else, Rails will reload by that autoload mechanism unless it's set to cache the result.

In production it is also configured by default to preload the classes, so it will load all the classes before even starting the server. That's to avoid the overhead of the whole const_missing, file searching and dynamic require thing.

Non-ruby files, like assets and views are all read by Rails at the time of request, so you can always change them without restarting Rails. (Note: on production assets are usually pre-compiled, so changing the assets inside app/assets won't result in any change. But it is still loading at the time of request, it's just that the file in question is a compiled bundle inside the public directory).

---

Original answer:

You need to restart you server when you need Rails to be loaded again from the start.

If you're adding or removing gems, then yes, you will need to restart the server.

If you change your version of ruby, change your Gemfile or change something from internal classes of Rails, you will need to restart it, otherwise it should be ok. But if unexpected problems arise, restart the server is the first thing you should try.

Also, on a side-note, you will only see the changes just refreshing the page if config.cache_classes is set to false (which I think is the default for development, but not for production).

Edit:

Just to make sure everyone will notice, tadman said one wise thing at the comments, The general rule of thumb here is making changes to anything outside of app/ or config/routes.rb or db/ will require a restart.

Do I need to restart Server : Ruby on Rails

You need to restart you server when you need Rails to be loaded again from the start.

If you're adding or removing gems, then yes, you will need to restart the server.

If you change your version of ruby, change your Gemfile or change something from internal classes of Rails, you will need to restart it, otherwise it should be ok. But if unexpected problems arise, restart the server is the first thing you should try.

Also, on a side-note, you will only see the changes just refreshing the page if config.cache_classes is set to false (which I think is the default for development, but not for production).

Making changes to anything outside of app/ or config/routes.rb or db/ will require a restart.

How should I restart spring in Rails 6

To stop spring you can use bin/spring stop. It should start automatically when you run rails commands.

Restarting Rails Server

Does this imply mongrel_rails is being
used?

Yes.

If so what's the best way to restart
the application to pick up my changes?

It depends on which Application server you currently use. Assuming the current recipe is ok, simply call the Capistrano restart task.

$ cap deploy:restart

---

Related Topics