Loading development environment (Rails 3.1.3)
1.9.3p0 :002 > Resque::Worker.working.each{|w| w.done_working}
# Removes data from your connection's CURRENT database.
| require 'active_record' | |
| require 'mysql2' | |
| # Database Connection | |
| ActiveRecord::Base.establish_connection( | |
| adapter: 'mysql2', # or 'postgresql' or 'sqlite3' | |
| host: 'localhost', | |
| database: 'chc_user_auth_direct_login', | |
| username: 'root', | |
| password: '' |
| # To Edit Root Cron Jobs | |
| #sudo crontab -e | |
| # Reboot 1 minute past every hour, log errors if any generate | |
| 01 * * * * /sbin/reboot > /home/calvin2/miner_cron_job_log.txt 2>&1 | |
| # Reboot every 30 minutes, log errors if any generate | |
| */30 * * * * /sbin/reboot > /home/calvin2/miner_cron_job_log.txt 2>&1 |
| # see http://stackoverflow.com/questions/5880962/how-to-destroy-jobs-enqueued-by-resque-workers - old version | |
| # see https://github.com/defunkt/resque/issues/49 | |
| # see http://redis.io/commands - new commands | |
| namespace :resque do | |
| desc "Clear pending tasks" | |
| task :clear => :environment do | |
| queues = Resque.queues | |
| queues.each do |queue_name| | |
| puts "Clearing #{queue_name}..." |
| mkdir -p ~/Library/Application\ Support/Sublime\ Text\ 3/Packages/CoffeeScript | |
| cd ~/Library/Application\ Support/Sublime\ Text\ 3/Packages/CoffeeScript | |
| curl -O https://raw.github.com/jashkenas/coffee-script-tmbundle/master/Syntaxes/CoffeeScript.tmLanguage | |
| curl -O https://raw.github.com/jashkenas/coffee-script-tmbundle/master/Preferences/CoffeeScript.tmPreferences |
http://robots.thoughtbot.com/post/47202759358/using-gdb-to-inspect-a-running-ruby-process
That’s not a great thing to have to say, is it? However, I bet you’ve said it before and may not have immediately know why.
With liberal use of puts and maybe pry, you can figure out what a problem might be next time you run it, but sometimes you need to figure out what that problem is right now.
As it turns out, and I know this is a shocker, Ruby processes are just regular processes. They can be debugged with gdb.
Having recently had the need to find out why a job of mine was running particularly slowly, I found out about this lovely tool the hard way: frantic googling. I found some very useful functions for gdb in a blog post by Rasmus on Ruby callstacks.
| select | |
| concat(table_name, '.', column_name) as 'foreign key', | |
| concat(referenced_table_name, '.', referenced_column_name) as 'references' | |
| from | |
| information_schema.key_column_usage | |
| where | |
| referenced_table_name is not null AND | |
| referenced_table_name = 'org_units'; |
| Change to root directory | |
| 1) cd / | |
| See size of each file/folder in directory with sorting | |
| 2) sudo du -sh * | sort -gr | |
| If /SomeFolder is over 1gb | |
| 3) cd SomeFolder && sudo du -sh * |
| This method only works if currently logged in as root. Sometimes when working with older ruby 'mysql' gems, after the 'mysql' gem is installed, the previous password doesn't work. | |
| 1) Already logged into Mysql | |
| 2) gem jacked up your mysql password | |
| 3) mysql > use mysql; | |
| 4) mysql > UPDATE user SET Password=PASSWORD('') WHERE User='root'; FLUSH PRIVILEGES; |
| Search git logs for tickets = 5803,5804,or5805 using regex. | |
| http://gitready.com/advanced/2009/01/20/bend-logs-to-your-will.html | |
| git log --grep=580[345] --stat -p --author=frank |