I have strange problem. After running rails s on some project, the script hangs with no output and no logs. How can I debug it and inspect what's going on? I use rvm with ruby 1.9.2.
check log/production.log to find the last file or line of code executed and try to figure out what went wrong.
If you want to dig a big deeper, you can use utilities such as "strace" or "dtruss" to see what files are being opened.
Linux:
$ strace rails s
Mac:
$ sudo dtruss rails s
You might not know what all of the output means, but you might get an idea if something is missing.
Related
I am fairly new to Ruby. I am have a problem getting my console to start a second time. I created my app (JacksApp) and created a model for it. I then shut down the app tried to restart the console a second time. When I type "rails c" I get this:
Running via Spring preloader in process 81129
Loading development environment (Rails 5.0.0.1)
No entry for terminal type "1.0.0/libexec:/Users/johnseabolt/.rbenv/shims:/Library/Frameworks/Python.framework/Versions/3.5/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin";
using dumb terminal settings.
irb(main):001:0>
I don't understand what's going on. Can someone help? I am in the directory for the app. I'm confused.
On MacOS Sierra, check TERM in Terminal.app
$ echo $TERM
xterm-256color
$ bin/spring stop
$ bin/rails c
No entry for terminal type "local/var/ry/rubies";
using dumb terminal settings.
irb> exit
$ bin/rails c
Cannot read termcap database;
using dumb terminal settings.
You can change TERM via Terminal > Preference > Profiles > Advanced > Terminfo > Declare terminal as: xterm.
Open new Terminal.
$ echo $TERM
xterm
$ bin/rails c
irb>
All sweet no warnings.
Now I leave it to someone with greater knowledge to explain why.
to fix this, you need to stop all rails processes and stop spring (bin/spring stop) and then make sure that you start up spring with an attached terminal.
There are basically three ways where spring would get started: bundle exec rails server, bundle exec rails console, or something like bundle exec guard or some other testing thing. If you start up rails through foreman, then it will run one of these commands, basically.
Starting the console will attach a input to the process, and this is where it will figure out the "terminal" type. Do that first, before everything thing else. Once that's loaded in memory, then its configured correctly, and starting up server or whatever will work find.
Server then console will give you the crazy error that you see. console then server will not.
Does it still let you use the console? The irb(main):001:0> at the end suggests that it is indeed working, you're just getting a warning about your terminal type setting being missing.
To fix the warning...If you're using a 3rd party terminal emulator, I'd reinstall that and see if that fixes it. Otherwise you can manually set your terminal type using export TERM=xxx in your ~/.bashrc file.
I'm following the instructions here http://railsinstaller.org/mac to get up and running with Rails on a Mac running OS X 10.8.2
At step 8 I'm asked to restart Rails server but how?
I'm assuming via a command line, but from within the already open ruby terminal window or a new one?
Now in rails 5 you can do:
rails restart
The output of rails --tasks:
Restart app by touching tmp/restart.txt
I think that is usefully if you run rails as a demon
Press Ctrl+C
When you start the server it mentions this in the startup text.
On OSX, you can take advantage of the UNIX-like command line - here's what I keep handy in my .bashrc to enable me to more easily restart a server that's running in background (-d) mode (note that you have to be in the Rails root directory when running this):
alias restart_rails='kill -9 `cat tmp/pids/server.pid`; rails server -d'
My initial response to the comment by #zane about how the PID file isn't removed was that it might be behavior dependent on the Rails version or OS type. However, it's also possible that the shell runs the second command (rails server -d) sooner than the kill can actually cause the previous running instance to stop.
So alternatively, kill -9 cat tmp/pids/server.pid && rails server -d might be more robust; or you can specifically run the kill, wait for the tmp/pids folder to empty out, then restart your new server.
In case that doesn't work there is another way that works especially well in Windows: Kill localhost:3000 process from Windows command line
if you are not able to find the rails process to kill it might actually be not running. Delete the tmp folder and its sub-folders from where you are running the rails server and try again.
I had to restart the rails application on the production so I looked for an another answer. I have found it below:
http://wiki.ocssolutions.com/Restarting_a_Rails_Application_Using_Passenger
I just reboot the server with
Ctrl + c
That worked for me
I've been trying to get Rails working, but whenever I try to create my own view, it returns a 500 error.
So, here's the steps I've followed to get where I am:
I installed Ruby to C:\Ruby
I installed Rubygems to C:\Ruby\rubygems-1.3.5 and ran ruby setup.rb
In the cmd prompt, I installed rails using gem install rails.
I created a Projects folder in C:\Ruby, and navigated to it in the cmd prompt
In the cmd prompt, I ran rails project1, then cd project1
In the cmd prompt, I ran ruby script/generate controller home index
In the cmd prompt, I ran ruby script/server
I haven't gotten any errors at all yet.
I go to http://localhost:3000, and everything is looking good.
I navigate to http://localhost:3000/home/index, and get this:
We're sorry, but something went wrong.
We've been notified about this issue
and we'll take a look at it shortly.
I have no clue why. Is there any troubleshooting I can do?
When you create a project with rails projectname the config-file is set to use the Active Record framework for using a database with your application. If you don't want to use a database, simply open:
\config\enviroment.rb
And set the following line:
# config.frameworks -= [ :active_record, :active_resource, :action_mailer ]
to:
config.frameworks -= [ :active_record]
Restart the server with CTRL+C, and then ruby script/server again. This should solve the problem.
As the other suggested, always have a look at \log\development.log to find the cause of such problems. I guess youre reads something like
Status: 500 Internal Server Error
no such file to load -- sqlite3
If you want to use a database with your application, see this guide: http://guides.rubyonrails.org/getting_started.html#configuring-a-database
Take a look at your development log at log\development, and look for a line that starts with
/!\ FAILSAFE /!\
The next lines below should tell you where to look for the error. If you cannot make out the issue, post the all lines from the log file that seem related.
Here's what I've determined:
Delta indexing works fine in development
Delta indexing does not work when I push to the production server, and no action is logged in searchd.log
I'm running Phusion Passenger, and, as recommended in the basic troubleshooting guide, have confirmed that:
www-data has permission to run indexing rake tasks (ran them from command line manually)
the path to indexer and searchd are correct (/usr/local/bin)
there are no errors in production.log
What on earth could I possibly be missing? I'm running Ruby Enterprise 1.8.6, Rails 2.3.4, Sphinx 0.9.8.1, and Thinking Sphinx 1.2.11.
Thanks!
Last night as I slept it hit me. Unsurprisingly, it was a stupid issue involving bad configuration, though I am rather surprised that it produced the results it did. I guess I don't know much about Thinking Sphinx internals.
Recently I migrated servers. sphinx.yml looked like this:
production:
bin_path: '/usr/local/bin'
host: mysql.mysite.com
On the new server, MySQL was just a local service, but I had forgotten to remove that line. Interestingly, manual rake reindexing still worked just fine. I'm intrigued that Thinking Sphinx didn't throw an error when trying to reload the deltas, since mysql.mysite.com no longer exists, even though that was clearly the source of the issue.
Thanks for all your help, and sorry to have brought up such a silly problem.
Are there any clues in Apache/Nginx's error log?
Here's the next troubleshooting step I would take. Open up the file for the delta indexing strategy you are using (presumably lib/thinking_sphinx/deltas/default_delta.rb). Find the line where it actually generates the indexing command. In mine (v1.1.6) it's line 20:
output = `#{config.bin_path}indexer --config #{config.config_file} #{rotate} #{delta_index_name model}`
Change that so you can log the command itself, and maybe log the output as well:
command = `#{config.bin_path}indexer --config #{config.config_file} #{rotate} #{delta_index_name model}`
RAILS_DEFAULT_LOGGER.info(command)
output = `#{command}`
RAILS_DEFAULT_LOGGER.info(output)
Deploy that to production and tail the log while modifying a delta-indexed model. Hopefully that will actually show you the problem. Of course maybe the problem is elsewhere in the code and you won't even get to this point, but this is where I would start.
I was having this problem and found the "bin_path" solution mentioned above. When it didn't seem to work, it took me a while to realize that I'd pasted in the example code for "production" when I was testing on "stagiing" environment. Problem solved!
This was after making sure that the rake tasks that config, index, and start sphinx are all running as the same user as your passenger instance. If you log into the server as root to run these tasks, they will work in the console but not via passenger.
I had the same problem. Works on the command line, not inthe app.
Turns out that we still had a slave database that we were using for the indexing, but the slave wasn't getting updated.
As above, same issues were faced our side on two machine. The first one we had an issue with mysql which showed in apache2 log. Only seemed to affect local OSX machine..
Second time when we deployed to Ubuntu server, we had same issue. Rails c production was fine, no errors, bla bla bla.
Ended up being a permissions problem. Couldn't figure this out as there were no problems starting, although I guess I was doing so as root.
Using capistrano and passenger, we did this:
Create a passenger user and added to www-data group
Changed user in deploy.rb to be passenger
Manually changed all the /current files to be owned by above
Logged in as passenger user.
Ran rake ts:rebuild RAILS_ENV="production"
Worked a treat for us...
Good luck
I am currently in the process of learning Ruby on Rails. I have been following the Learning Rails podcast and screencasts.
I've run into a problem, well more of an annoyance. Every time the screencast has me kill the mongrel server I am forced to close the console window because CTRL+C isnt killing it as it should. I then have to open a new console window, navigate to my rails app and issue a 'ruby script/server' command to restart it.
What I am looking for is possibly a reason for this, a way to fix it or other suggestions to make this process faster and/or less annoying. Or even possibly a batch file or shortcut to open a cmd window right to where I need it?
Use Ctrl+Pause/Break instead. It will stop the server.
Ctrl+Pause/Break force closes the server. It's not normal. Anyways my Dell notebook does not have the key.
So use this:
instead of rails s use ruby script/rails s.
Ctrl+C will work perfectly with that. Tested it.
It's a known issue and here is the patch:https://rails.lighthouseapp.com/projects/8994/tickets/2088-mongrel-not-being-stopped-with-ctrl-c-under-windows
I believe this can happen if you are catching Exception and not re raising it. SIG-INT would be caught there and ultimately not kill the process.
If all fails, hit Ctrl+Alt+Delete, open the task manager and just kill the ruby process ;)
I have the same problem on Windows as well, so can't help you in fixing the Ctrl+C issue. But, I can point you towards Windows PowerToys' Open Command Window Here - it adds "Open Command Window Here" to your Explorer window, it's a requirement for development (of any sort) on Windows machines.
If you start mongrel a little different like this:
$ cd myrailsapp
$ mongrel_rails start
then you can stop it like this:
$ mongrel_rails stop
You can get more info here. This might be interesting to: Mongrel as a service
After you hit Ctrl+c, send a request to the server by refreshing your browser page where you had it open. The command prompt will now say Exiting and let you back to the command line.
Check your rails version and use
ctrl+c+pause/break for 2.3.2
ctrl+c for 2.1.2