I'm using ROR on a Ubuntu server.
I remember the first time I start ROR use rails s,
I can see all logs, server status in the window
Now I start it as background function.
When I need to check the log, I need to open WinSCP, find development log the huge file and open it.
The time for downloading the file takes minutes.
Actually I dun need to see all log, I need only view last say 10-20 lines.
How can I do that?View last 10-20 development log without influence the ROR server.
This should work (assuming that you're already in your Rails project's main directory):
tail -f -n=20 log/development.log
Also, this command is outputting new lines continuously as they appear in log (because of modifier -f).
Related
I got my production log file working. But wanted to get some suggestions onto how to work with it. I currently look at it view console and doing either
tail log/*
tail -f log/production.log
to look at it. I would like to either 1. find a better way to be able to look at the logs and perhaps with colors. 2. Can the production log file be outputted in a view where an admin user can view it?
Lastly, is there a gem that's great for emailing me when an error occurred and what the error was / how do you currently keep track of when errors happening in production?
Thanks!
For just having a nicer alternative to tail which shows the colours instead of those ESC[… codes, try less -R production.log. If you want to follow the end of the file like tail -f, use:
less -R +F production.log
There's nothing built-in for getting the log into a view as far as I know, but I suppose you could write a controller which shows (some of) the log in a view. Make sure it's secure with authentication though; you don't want to be exposing your log to the internet! Using an external service should remove this concern and it will have a load of other features. For example, I haven't tried papertrail (https://papertrailapp.com) but it's been on my to-try list for a while. It looks good and they're free for up to 100MB of logs a month. I've used airbrake (https://airbrake.io/) in the past for exception notifications but I don't think they have a free tier - just a free trial.
I'm completely new to Ruby on Rails, have never worked on it, but I am supposed to take over somebody else's old project. He designed a webapp that logs into a website/server online, extracts data from it daily and performs calculations. However, the application has not been running for quite some time, so now when it tries to display statistics, the page crashes. It uses data from a 5 week period and currently only has data for 2 days.
I need to manually insert data for the missing weeks in order to get it up and running again, but the problem is I don't know how to find/access its database, nor how exactly to use Ruby on Rails. I found several files in the db directory of his project, however they were mostly .sqlite33 files or just 'files'. I downloaded sqlite precompiled binary for Windows and tried to use it, but not sure what to do. I also downloaded and tried using SQTView to open the files to change the tables, but I have had no luck.
How can I tell which file is the main database and how do I edit it? And what are .sqlite33 files? Thanks.
EDIT
The application produces a
TypeError in HomeController#index
"nil can't be coerced into Float"
It links the error to a line in the code, but the only reason the error happens is because there is no data in the table for the time period that the variable in this line of code tries to use. That is why I want to manually update it with values.
I think that Sqliteman might do the trick and thank-you for explaining all of this to me. I just have to confirm it works after editing.
EDIT2
Okay, so I had a small revelation while experimenting on his app. It turned out that the page crashed because of empty values for full weeks. If I used the app to gather data for at least one day per week up until this week, then the app worked.
Is there a way I can populate all the missing days without having to manually click the days in its calendar because it takes a good 20-30 seconds for it to load?
Thank you very much for your help.
A Rails application's database is defined in config/database.yml - though the database itself and the scheme are in the db folder. In database.yml you'll find three database configurations - development, test and production - so make sure to choose the right file.
I've never heard of .sqlite33 files, but to edit SQLite files manually I recommend SQLiteMan. But I don't recommend editing it manually.
What I do recommend is to check if you are running the app in development or production mode, as the two mods use different databases. Try to run it in the other mode.
If that doesn't work, try saving a copy of the database files, and running the commands:
bundle install
bundle exec rake assets:precompile
rake db:migrate
rake db:migrate RAILS_ENV="production"
(if you're using Linux, you might want to also run the first command with sudo)
Those commands make sure all the required gems are installed, that the precompiled assets are up to date, and that the database fits the schema. If you are running that application on the same machine and with the same database as the ones the other guy was using, than those commands shouldn't be necessary, but if you have moved the application to your own machine, or used an used an outdated db file, than those commands might fix the crash.
At any rate, if you tell us what error the application is producing we might be able to provide more assistance.
I'm frequently starting up rails console or rails server or using other command line ruby apps. The bootstrap takes several seconds, which becomes tedious after a while.
Is there any way I can either run a compiled version, or keep it loaded using something like spork, so running 'heroku logs' runs instantly, rather than taking 10 seconds to start up?
Run a compiled version of what?
Rails server and rails console take long time to load because they have to load up Ruby on Rails plus whatever your environment requires. If you want to keep instances running then just open up a terminal window, load your console and server, and never close them.
Have you thought of trying vagrant? it will keep your instance running to you want them to stop.
I help to maintain a Rails website. It's running JRuby 1.5.5, Rails 2.3.10, on a Solaris Sparc machine. I have a problem related to logging.
To stop our logfiles growing too large and filling the disk, we're using the log-shifting that's built in to the Logger class. In config/environments/production.rb we have:
config.logger = Logger.new(config.log_path, 10, 100.megabyte)
Which should rotate the logfiles when they reach 100 megabytes, and only keep 10 files.
The problem is two-fold: Rails is not rotating the logs properly, and it is keeping open the old log file to write to it -- but what it is writing is just repeated content of a few requests. So if I do ls -l log I see something like this:
-rw-r--r-- 83040892 Oct 4 15:07 production.log
-rw-r--r-- 3303158664 Oct 4 15:07 production.log.0
-rw-r--r-- 104857616 Oct 2 23:13 production.log.1
-rw-r--r-- 104857618 Oct 1 17:12 production.log.2
Note how the most recently cycled log is still open and still being written to (running pfiles confirms that it the Rails server still has three file handles to the log). Note also that it has reached 3 gigabytes in two days, where usually we do 100MB a day. This is because it is full of repeated requests. I can't easily paste it in here, but the log is full of the same 1000 line chunk of requests from 18:50 on Oct 3 (which I believe is the point at which the logs rotated), printed over and over again. From past experience, the log file will keep filling with this repeated content until the disk fills up.
Is log shifting/Rails logging just plain broken? (There's nothing odd about our logfile usage: we don't do any direct logging, it all just comes from the Rails framework.) The obvious next step is to try something like logrotate, but if Rails is refusing to close old log files and is writing junk to them forever, I suspect it won't solve my problem (because the log will never be closed, and thus the disk space never recovered).
The symptom seems to be that one old logfile still keeps getting used, although you successfully rotated the logs.
The cause is most likely that one or more of your Rails instances or threads is still using the old file handle.
The solution is to make sure that all the Rails instances restart completely after logs are rotated, so they all use the new file handle / name.
Use logrotate instead of config.logger to rotate your logs!
I'd suggest to use the UNIX logrotate to rotate your logs, instead of config.logger.
IMHO that's a better solution, more reliable, you have more control over the log rotation, and you can provide some post-rotation commands to restart your Rails processes. (either via logrotate's postrotate or endscript option)
See:
http://www.opencsw.org/packages/logrotate/ (logrotate Package for Solaris)
http://www.thegeekstuff.com/2010/07/logrotate-examples/ (logrotate tutorial with examples)
http://linux.die.net/man/8/logrotate
Can you use Unicorn?
- Unicorn is has built-in support for re-opening all log files in your application via USR1 signal - this allows logrotate to rotate files atomically...
- Unicorn keeps track of and restarts it's workers! You can kill the workers after log rotation and Unicorn will restart them, making sure they use the new log file.
See: https://github.com/blog/517-unicorn (many advantages for Unicorn over Mongrel)
If you're using Mongrel and can't switch to Unicorn:
use logrotate, and restart your Mongrels via the postrotate option.
hope this helps..
I've always used the platform's log rotation mechanism when dealing with the Rails log files. Following the advice from http://www.nullislove.com/2007/09/10/rotating-rails-log-files/ and because I run Passenger from http://overstimulate.com/articles/logrotate-rails-passenger as well.
The first method uses the logrotate copytruncate method of creating the new log file, so processes that still have a handle to it will always write to the current log file.
Other things to check on the server are:
Make sure that none of the gems or plugins have a handle to the Logger inside the ruby context.
Since you're using JRuby ensure that there isn't a stuck/runaway thread somewhere that's trying to fulfill a request but getting stuck logging.
Just like with Passenger, consider restarting the Rails server processes every now and again. I know this is effectively a hack but it might work.
Neil,
I don't know if this works for your particular situation, but I was having a similar problem and I think I just solved it. In my case, I had two symptoms. The first was the same issue as you -- my log rotation was screwy...in particular, the production.log.1 file was kept open and continued logging to is was happening while production.log was also getting logged to. The second symptom was that the log files ownerships and group memberships would keep changing to root. My Rails app is deployed via Capistrano, using a 'deployer' user, so I'd get all sorts of neat errors whenever the app tried to write to a log file that was no longer owned by deployer.
I'm embarrassed to say how long it took me to realize what the cause of both problems was. Somewhere along the way, I updated cron with the app's crontab as root. This must have been when I messing around at the command prompt...if I had just stayed with my deployment recipe via Capistrano, I wouldn't have inadvertently done that. In any case, I finally looked in /var/spool/cron/crontabs and I found two copies of my crontab file...one for deployer and one for root. So, the processes that cron fired off for my app were getting duplicated -- one was run under deployer and a second under root. It was that second one that was screwing things up. Once I deleted root's crontab, all was better.
Some caveats: on my setup, there were no non-app-related tasks in root's crontab, i.e. it was an exact duplicate of deployer's crontab...so deleting it had no side effects for me. Also, my server is running Ubuntu...the path to your crontabs may be different.
Hope that helps.
David
I think you forgot the 's' in megabytes
or instead use something like this
config.logger = Logger.new(config.log_path, 10, 102400)
also check this link it's very helpful
http://railsillustrated.com/logger-tricks.html
Rails appends a timestamp to js and css files to force cache refreshes while in development mode. While this is appropriate most of the time, it backfires when using CSSEdit, for example, that does not take the timestamp append into consideration.
If you attempt to create a new style or edit an existing selector it will attempt to reload the page each time, even though you've opened a file once. This is a conversation I had a long time ago with Jan, however I've never seen a mechanism added to address this situation.
Is anyone aware of either:
A) a hack to allow CSSEdit to cut off the ?##### timestamp or
B) just simply temporarily disable rails timestamps via the rails server command (or perhaps just throw an awk into it to change a config file via a script to start the rails dev server on localhost)?
RAILS_ASSET_ID='' rails s actually does the trick for anyone needing to work with CSSEdit and Rails to temporarily disable the modification postfixes when dealing with the cache-buster.
This is handy since it's a temporary solution and will go back to the normal operation when you go back to running rails without the RAILS_ASSET_ID command prepend.