I am using cloud9, so to run the server I have to type in the command Rails S -b $IP -p $PORT. How can I shorten it to Rails S using .bashrc?
Thanks!
OK, you can do this on cloud9 using alias in .bash_aliases file, but you can't exactly Rails S because alias naming convention not supported space in a variable.
On your cloud9 .bash_aliases file use like below
alias RailsS="rails s -b $IP -p $PORT"
or
alias Rails_S="rails s -b $IP -p $PORT"
or
alias rails_s="rails s -b $IP -p $PORT"
or
alias rs="rails s -b $IP -p $PORT"
or
alias rails_server="rails s -b $IP -p $PORT"
or what do you want
After that you can restart your cloud9 workspace otherwise the .bash_aliases won't be recognized as updated. That's it.
Now use which variable you have defined to your .bash_aliases file. If you have used this alias rs="rails s -b $IP -p $PORT" then you can write the command rs and hit enter, see the below
$ rs
=> Booting Puma
=> Rails 5.1.4 application starting in development
=> Run `rails server -h` for more startup options
Puma starting in single mode...
* Version 3.11.2 (ruby 2.3.4-p301), codename: Love Song
* Min threads: 5, max threads: 5
* Environment: development
* Listening on tcp://0.0.0.0:8080
Use Ctrl-C to stop
Started GET "/" for 114.31.20.44 at 2018-03-18 10:10:02 +0000
Done! :)
Now question is where you will find this .bash_aliases file, Right?
Don't worry! this so much easy to find this.
You will find it on the left side Workspace->Setting Icon->Show Hidden Files, You can click on the left side upper right settings icon click it then it will show a list then you can click Show Hidden Files
See the attached images
Click to pollup this.
Hope it helps.
Related
I'm new to Heroku and despite all the documentation, I'm a little unsure what the profile is for. I can set a port and the environment as follows, but Heroku always starts in production mode (which makes sense) and not with the specified port.
I suppose that the port cannot be set because it is determined by Heroku?
Is the Procfile only for the command "heroku local" to test?
Because when I run "heroku ps" I get info about the procfile, but the API runs without the procfile port in production mode.
Thank you for any explanation!
Procfile:
web: bundle exec puma -t 5:5 -p ${PORT:-3000} -e ${RACK_ENV:-development}
Output of heroku ps after deploying:
=== web (Hobby): bundle exec puma -t 5:5 -p ${PORT:-3000} -e ${RACK_ENV:-development} (1)
web.1: up 2020/07/27 13:50:23 +0200 (~ 1m ago)
Output of heroku logs at the same time:
Version 3.12.6 (ruby 2.5.8-p224), codename: Llamas in Pajamas
2020-07-27T11:49:32.219309+00:00 app[web.1]: * Min threads: 5, max threads: 5
2020-07-27T11:49:32.219309+00:00 app[web.1]: * Environment: production
2020-07-27T11:49:33.740321+00:00 app[web.1]: * Listening on tcp://0.0.0.0:10269
Heroku will set both $PORT and $RACK_ENV for Rails apps when they're deployed. You can confirm this by running heroku config --app <yourapp>. The construct ${PORT:-3000} means "use the PORT variable if it's present, otherwise use the value 3000.
In any case, you can't run a Heroku app on a port other than the one defined in $PORT, which is randomized for each dyno. Whatever that's set to will be forwarded to from ports 80 and 443 for HTTP/S.
If you want to override the RACK_ENV, you can run heroku config:set RACK_ENV=development.
When I run rails s -e production -p 9292 (normal case), I get:
=> Booting Puma
=> Rails 5.1.1 application starting in production on http://0.0.0.0:9292
=> Run `rails server -h` for more startup options
Puma starting in single mode...
* Version 3.8.2 (ruby 2.3.0-p0), codename: Sassy Salamander
* Min threads: 5, max threads: 5
* Environment: production
* Listening on tcp://0.0.0.0:9292
Use Ctrl-C to stop
When I run rails s -d -e production -p 9292 (as daemon), I get:
=> Booting Puma
=> Rails 5.1.1 application starting in production on http://0.0.0.0:9292
=> Run `rails server -h` for more startup options
That's it. I would need to run bundle exec puma -e production -p 9292 --pidfile tmp/pids/puma.pid -d to get the 2nd part:
Puma starting in single mode...
...
Also where are my Puma logs? I see a blank production.log in my log folder and no other log files.
Background context: When I run curl 0.0.0.0:9292 after running both rails and puma as daemons, I get the error An unhandled lowlevel error occurred. The application logs may have details.
rails s -e production -p 9292 -d
Ah, seems Puma only cares about RAILS_ENV when used with capistrano. Can you use RACK_ENV or use -e instead? That should work:
RACK_ENV=production bundle exec puma -p 3000
or
bundle exec puma -p 3000 -e production
See here
Hope to help
to kill the server
kill cat tmp/pids/server.pid
rails s -e production -p 9292 -d
For Puma Versions Below 5, we can use -d option to start in background.
puma -e production -p 4132 -C config/puma.rb -d
But Puma gem does n't support -d option in versions above 5.
In version 5.0 the authors of the popular Ruby web server Puma chose
to remove the daemonization support from Puma, because the code wasn't
wall maintained, and because other and perhaps better options exist
(such as systemd, etc), not to mention many people have switched to
Kubernetes and Docker, where you want to start all servers on the
foreground
You can use this gem for starting in background.
https://github.com/kigster/puma-daemon
https://rubygems.org/gems/puma-daemon/versions/0.1.2
I have made some changes to various files, and need to shut down and then restart the server to see them. I am using the Cloud9 railstutorial environment. But I keep getting the same error - "A server is already running". Please see below:
darrenbrett:~/workspace/sample_app (filling-in-layout) $ rails server -b $IP -p $PORT
=> Booting WEBrick
=> Rails 4.2.2 application starting in development on http://0.0.0.0:8080
=> Run `rails server -h` for more startup options
=> Ctrl-C to shutdown server
A server is already running. Check /home/ubuntu/workspace/sample_app/tmp/pids/server.pid.
Exiting
darrenbrett:~/workspace/sample_app (filling-in-layout) $
Find out the process id (PID) first:
$ lsof -wni tcp:8080
This will give you something like this:
$ lsof -wni tcp:8080
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
ruby 59656 rislam 14u IPv6 0xa86b8563672ef037 0t0 TCP [::1]:http-alt (LISTEN)
Then, kill the process with PID = 59656 (for example, it will be different for you):
$ kill -9 59656
This should solve your problem.
You can also use the following command to kill all running apps that has rails in the name:
killall -9 rails
Sometimes, this is very effective when the first command does not do the trick.
It sounds like you either have an orphaned server process running, or you have multiple applications in the same environment and you're running the server for another one and it's bound to the same port. I'm guessing the former.
Run ps -fe | grep rails. You should see something like 501 35861 2428 0 1:55PM ttys012 0:04.00 /your_file_path/ruby bin/rails server
Grab the process id (in the case of the example, it's 35861), and run kill -9 35861. Then try to start your server again.
The easiest way I found to kill that server is to click on the suggested file in the line:
A server is already running. Check /home/ubuntu/workspace/sample_app/tmp/pids/server.pid
That opens the file containing a number, the process id you're looking for.
Example
43029
In the terminal window use "kill" via that same process id and restart the server.
kill -15 43029
rails server -b $IP -p $PORT
Using a vanilla rails install using git (in fact following the heroku guide here https://devcenter.heroku.com/articles/rails3)
However it mentions the creation of a Procfile
web: bundle exec rails server thin -p $PORT -e $RACK_ENV
Yet if you run this is needs using foreman start, you receive an error because you haven't defined the RACK_ENV
20:45:26 web.1 | started with pid 26364 20:45:27 web.1 |
/SomeLocalPath/.rvm/gems/ruby-1.9.2-p318/gems/railties-3.2.2/lib/rails/commands/server.rb:33:in
`parse!': missing argument: -e (OptionParser::MissingArgument)
Where should this -e argument be stored for this all to work?
I guess you mean that you are getting this error on your local development machine.
You can set the RACK_ENV when starting foreman like this, for example:
RACK_ENV=development foreman start
Or you could use a different procfile for development (e.g. "Procfile-dev") which has the value for the option -e inline, like this:
web: bundle exec rails server thin -p 3000 -e development
and call it with:
foreman start -f Procfile-dev
(On Heroku, it should just work, because when you run "heroku config -s" while you are in your app-folder, you should see "RACK_ENV=production", so the needed environment variable is set correctly here).
Is there a way to restart the Rails app (e.g. when you've changed a plugin/config file) while Mongrel is running. Or alternatively quickly restart Mongrel. Mongrel gives these hints that you can but how do you do it?
** Signals ready. TERM => stop. USR2 => restart. INT => stop (no restart).
** Rails signals registered. HUP => reload (without restart). It might not work well.
You can add the -c option if the config for your app's cluster is elsewhere:
mongrel_rails cluster::restart -c /path/to/config
1st discover the current mongrel pid path with something like:
>ps axf | fgrep mongrel
you will see a process line like:
ruby /usr/lib64/ruby/gems/1.8/gems/swiftiply-0.6.1.1/bin/mongrel_rails start -p 3000 -a 0.0.0.0 -e development -P /home/xxyyzz/rails/myappname/tmp/pids/mongrel.pid -d
Take the '-P /home/xxyyzz/rails/myappname/tmp/pids/mongrel.pid' part and use it like this:
>mongrel_rails restart -P /home/xxyyzz/rails/myappname/tmp/pids/mongrel.pid
Sending USR2 to Mongrel at PID 18481...Done.
I use this to recover from the dreaded "Broken pipe" to MySQL problem.
in your rails home directory
mongrel_rails cluster::restart
For example,
killall -USR2 mongrel_rails