I am running a local puma server for my rails app.
This is in my local_env.yml file
STAGING_URL: 'http://statrubytwotwo.test'
I can hit the URl when the server is running and all works fine. If I shut the server down with Cntrl-C and then hit the server it is still running.
To get the server to shutdown I have to do
pkill -9 -f 'rb-fsevent|rails|spring|puma'
The main problem is I change code. Do a git add * --all and a git commit -m "something here" and then start the server via bundle exec puma
The server starts up again, but the code changes are NOT seen. The puma server is running the old code?
UPDATE ====
I killed all with the following:
puma-dev -stop
pkill -9 -f 'rb-fsevent|rails|spring|puma'
pkill -USR1 puma-dev
I did a rails s and I see this
Puma starting in single mode...
* Version 3.11.4 (ruby 2.3.1-p112), codename: Love Song
* Min threads: 0, max threads: 16
* Environment: staging
* Listening on tcp://0.0.0.0:3000
Use Ctrl-C to stop
I hit the https://stattwotwo.test domain and it loads.
I hit http://localhost:3000 and NOT FOUND
I hit the https://stattwotwo.test domain and it loads
No matter what I do nothing ever loads on http://localhost:3000
I believe I recall the puma-dev will start anytime the domain is hit even if it is down (forman or pow)? Either way when it restarts it is not using new code.
Adding as a response because I can't fit it all in a comment:
You need to find out which tool you're using. My guess would be puma-dev, and you installed it as a background process via here
See if you can confirm.
Normally you'd get a conflict if there were 2 servers running, but that runs on a port other than the puma/rails default of 3000, which is what default bundle exec puma runs (I think?)
If that's the case, you've been starting a new server on a different port, while the old server (running your old cached code from when it started) is still running. That's why you don't see the changes.
You can confirm a couple things:
Don't do bundle exec puma, do rails s and check the log to the screen and see if :3000 is there
Kill your puma like you've been, but visit your URL and see if it's still running
Start rails s again, and visit http://localhost:3000 and see if your code changes when you reload pages as you expect.
Do puma-dev -stop, then rails s, and visit your .test url and see if it breaks (that means puma-dev was running in the background)
Related
When I run :
$ rails server
It comes:
=> Booting Puma
=> Rails 5.0.1 application starting in development on http://localhost:3000
=> Run `rails server -h` for more startup options
Puma starting in single mode...
* Version 3.6.2 (ruby 2.3.0-p0), codename: Sleepy Sunday Serenity
* Min threads: 5, max threads: 5
* Environment: development
* Listening on tcp://localhost:3000
Use Ctrl-C to stop
So I can not type in command in this Terminal, so if is I must open an other Terminal by command + N to type commands?
try
rails server -d
it will run rails server as detached.
As pointed out by a comment of #Sairam to the original question (where he asks me to create an answer, too):
These explanations should be true for most if not any Linuxes/Unixes .
If you append an & to your command, it will be directly send to the background:
rails server &
If you enter
jobs
you should now see that there is a job running the background.
To get this command "back" (if it did not crash, it is still running anyway), call
fg
.
To make a break and temporarily stop this command from executing, use Ctrl+Z.
You are now back in the shell. jobs will show you what happened (job is now "Stopped").
So, you have a "Stopped" job and are in the terminal. To push this job to the background (and let it continue to do its job), call
bg
(for "background" ...).
Now, if you want to have it back, call (you get it) fg, and so on...
Note that using this approach (versus e.g. rails server -d), you have slightly more/easier control, and your command will get killed with your terminal-session. So, when you close your terminal, the rails server will go byebye, too. You would usually use screen (or other alternatives) if you don't want that.
to start any job in the background on bash, append it with &
rails server &
You can use fg to get it to foreground.
To put any the job back to the background, use Ctrl + Z and then bg to push it to the background.
NOTE: All stdout/stderr will continue to write to the terminal on bg
if using a mac just type command + t to open a new terminal tab and Ctrl + C to kill the server you can also you use the rails console which is rails c to run.
The deployment was successful and everything is green. But when we try to access the application URL, it gives 502 Bad Gateway error.
Checking for puma process with ps -aux | grep puma doesn't return any process attached to puma server but pgrep returns following.
$pgrep -fl puma
18009 su -s /bin/bash -c bundle exec puma -C /opt/elasticbeanstalk/support/conf/pumaconf.rb webapp
18031 ruby /opt/rubies/ruby-2.0.0-p598/bin/puma -C /opt/elasticbeanstalk/support/conf/pumaconf.rb
I have tried all possible combinations, as shown in every other forum/blog OR support sites of nginx/puma. Following is the status.
Default configuration - Where we have UNIX:// sock file used in the UPSTREAM option of nginx.conf and pumaconf.rb - This gives 502 bad gatway. When checked, puma is not running and it is rebooting every 3rd minute.
As we have used it in DigitalOcean - Change the above UPSTREAM conf URL to tcp://127.0.0.1:3000 in pumaconf.rb and 127.0.0.1:3000 in conf.d/webapp.conf file. - This is also not working, puma is not able to run properly same as above.
My question is,
Why there is no control over running puma with diff. configurations? And why we have to always use the UI, which is not able to run the services properly as per other standard configuration options?
There is no configuration options from UI, to change/verify from the UI. So we have to do it from SSH. But, we have no control over rebooting PUMA from console.
Whenever puma is not running, we are not able to see any logs of what error it is facing. This is really not helpful at all.
Puma is not able to run even with default configurations, so it nginx is not able to talk to Puma and so the EC2 does not really make sense!
Please let us know, how we can resolve this issue, if you have any idea on this.
See this - https://forums.aws.amazon.com/thread.jspa?messageID=608148򔞔
Still no answers on this one, this is like our hands are cuffed and not able to change any configurations!
UPDATE
AWS is somehow stopping and starting PUMA, because i can see the process IDs changing when checking with ps -ef|grep puma. So, I started the puma to work on another port and tried to check if it runs or not.
Started on another port, and then from another console accessing the URL using wget http://127.0.0.1:3000. It prints the following log.
current]$ bundle exec puma -b tcp://127.0.0.1:3001
Puma 2.0.1 starting...
* Min threads: 0, max threads: 16
* Environment: production
* Listening on tcp://127.0.0.1:3001
Rails Error: Unable to access log file. Please ensure that /var/app/current/log/production.log exists and is chmod 0666. The log level has been raised to WARN and the output directed to STDERR until the problem is fixed.
Use Ctrl-C to stop
2015-03-16 13:19:35 +0000: HTTP parse error, malformed request (): #<Puma::HttpParserError: Invalid HTTP format, parsing fails.>
2015-03-16 13:19:35 +0000: ENV: {"rack.version"=>[1, 1], "rack.errors"=>#<IO:<STDERR>>, "rack.multithread"=>true, "rack.multiprocess"=>false, "rack.run_once"=>false, "SCRIPT_NAME"=>"", "CONTENT_TYPE"=>"text/plain", "QUERY_STRING"=>"", "SERVER_PROTOCOL"=>"HTTP/1.1", "SERVER_SOFTWARE"=>"2.0.1", "GATEWAY_INTERFACE"=>"CGI/1.2"}
So, is it compulsory to use SSL? Because I think by default, it is not enabled.
I had this issue after uploading my rails app, I found this line (auto generated) on secrets.yml (config > secrets.yml) :secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>
so you have to add it as an environment variable to your environment.
In the environment dashboard go to Configuration > Software > Environment properties and add a new variable with name SECRET_KEY_BASE.
You can set any value but make sure it is a safe key.
This resolved the issue for me, I hope it helps.
I could not fix this problem. Also we supposed to use EC2 free instance only instead of BeanStalk.
We have now moved to Free EC2 instance with RDS and deployed the rails application using Capistrano with Nginx + Unicorn. Though it was not easy[1][2] but finally we got it working.
I have deployed my rails application on EC2. It runs on two servers. One for rails application and second for DB.
When I start application using "rails s -e production&" and if I stay connected using SSH,
I can see the webpages.
As soon as I disconnect SSH I can not see the pages.
There are no errors thrown. One weird thing is "Production.log" file does not have anything.
everything is spit out on console.
You are running rails in the current ssh session. Any programs you have running during that session will stop if you disconnect. You need to set up your rails app to run as a daemon using something like Phusion Passenger.
You are basically running the built in WEBrick server that is not really meant for production so it's likely that the process is getting killed after the parent process (your ssh process) gets terminated.
You can probably tweak the configuration to make WEBrick not quit, or you can simply run your session using screen or tmux
Screen:
$ screen
$ rails s -e production &
$ screen -d
When you want to reattach:
$ screen -r
Tmux:
$ tmux
$ rails s -e production &
$ # Hit <ctrl-b><ctrl-d> to detach
When you want to reattach:
$ screen attach -t 0
Or like #datasage mentioned you can run your Rails with an actual production web server like Passenger Phusion or Unicorn.
On my server, I can start my rails application server (puma) and give my application a UNIX socket by cd'ing into the application's root directory and issuing the following command:
bundle exec puma -e production -b unix:///var/run/my_app.sock
Everything works great, expect that my terminal to the server is now useless:
Puma starting in single mode...
* Version 2.6.0, codename: Pantsuit Party
* Min threads: 0, max threads: 16
* Environment: production
* Listening on unix:///var/run/my_app.sock
Use Ctrl-C to stop
This may be majorly n00by but I literally don't know what to do here.
I can't CTRL-C, because that would stop puma.
I can't just close my terminal window because that too would stop puma.
Conundrum!
You can use the --daemon option to make puma fork to the background. That way, it will free your terminal as soon as it ends the startup process.
To make the process exit afterwards, you need to send it the TERM signal:
kill -TERM $PID
Where $PID stands for puma's process id. The easiest way to get that on a server is to ask puma to save its pid on a file (a, suitably named, "pidfile"), using the --pidfile option when starting it up.
For more options, check out puma's documentation and examples on github: https://github.com/puma/puma
Hi I'm new to Ruby on Rails. I have installed the Testia Tarantula application and am trying to read up on Ruby.
My question is how do I start/stop the server.
For example: I want to change the Admin email, so I execute the following command to change the configuration of the app:
RAILS_ENV=production rake db:config:app
But is this command ok to execute while the server is running, it has 'db' in the command which is what would warn me that I shouldn't run it while the server is up. Anyone have some helpful tips for learning Ruby on Rails server app management?
Welcome to Rails!
You can run rake db:xxxxx while the server is running and it won't hurt anything. However I usually stop my server, run my rake command and then start it back up to ensure that all changes will be picked up. If running in production, I would think you may want to restart the server just to make sure. I believe that the schema is generated/updated upon server startup, just fyi.
As far as starting and stopping the server, if you are attached to it you can just use ctrl + c. If it is detached, you can search for the pid and then kill -9 .
Running rake db:anything will load rails on its own. It doesn't matter if you have a server up or not. This will happen in the background. Think of it as the same as running a sql script while the server is running. It's a separate process.