I am using PostgreSQL, Rails 3.1.3 and Ruby 1.9.3. I am struggling to use db:migrate as outlined here.
This is what I am seeing in the terminal:
funkdified#funkdified-laptop:~/railsprojects/hartl$ bundle exec rake db:migrate --trace
** Invoke db:migrate (first_time)
** Invoke environment (first_time)
** Execute environment
** Invoke db:load_config (first_time)
** Invoke rails_env (first_time)
** Execute rails_env
** Execute db:load_config
** Execute db:migrate
== AddEmailUniquenessIndex: migrating ========================================
-- add_index(:users, :email, {:unique=>true})
and then the code hangs at this point. Any ideas why?
From: development.log
[1m[36m (0.1ms)[0m [1mSHOW search_path[0m
[1m[35m (0.5ms)[0m SELECT "schema_migrations"."version" FROM "schema_migrations"
Migrating to CreateUsers (20120124022843)
Migrating to AddEmailUniquenessIndex (20120124093922)
[1m[36m (0.1ms)[0m [1mBEGIN[0m
[1m[35m (3.6ms)[0m SELECT distinct i.relname, d.indisunique, d.indkey, t.oid
FROM pg_class t
INNER JOIN pg_index d ON t.oid = d.indrelid
INNER JOIN pg_class i ON d.indexrelid = i.oid
WHERE i.relkind = 'i'
AND d.indisprimary = 'f'
AND t.relname = 'users'
AND i.relnamespace IN (SELECT oid FROM pg_namespace WHERE nspname = ANY (current_schemas(false)) )
ORDER BY i.relname
I just had a similar problem, where a very simple migration was stalling for no apparent reason. I believe the problem has to do with not being able to get a database connection. I exited a rails console session that I had open in another terminal and then the migration immediately finished with no problems.
I had same problem .. I found out that there was idle transaction which blocked further queries on this table ..
Run:
heroku pg:ps --app=...
To view database processes. You will have to kill idle process:
heroku pg:kill 913 --force --app=...
(913 is ID of idle process -> change it to your needs)
I just made two migrations. The first one created a new table, the second one removed fields from an existing table. The second migration was hanging, and the reason turned out to be a rails console session (rails console --sandbox) running in another terminal windows.
I had the same issue and after trying a bunch of solutions what worked was...shutting down all of my terminal sessions, restarting the computer, and trying again. Sometimes it's just power cycle magic.
Related
I am using Ruby on Rails 5.2.0 to develop a system and I need to run a job every 2 minute.
I'm using sidekiq for background processing and sidekiq-cron for scheduling jobs.
I execute the following line in rails console:
job=Sidekiq::Cron::Job.new( name: 'TestWorker_Job', cron: '*/2 * * * *', klass: 'PriceWorker')
And this is the answer
=> #<Sidekiq::Cron::Job:0x000055b6d54707e8
#active_job=false,
#active_job_queue_name_delimiter=nil,
#active_job_queue_name_prefix=nil,
#args=[],
#cron="*/2 * * * *",
#fetch_missing_args=true,
#klass="PriceWorker",
#last_enqueue_time=nil,
#message={"retry"=>false, "queue"=>"default", "class"=>"PriceWorker", "args"=>[]},
#name="TestWorker_Job",
#queue="default",
#queue_name_with_prefix="default",
#status="enabled">
But it throws me an error:
job.errors
=> ["'cron' -> */2 * * * *: uninitialized constant Rufus::Scheduler::CronLine"]
There is no valid job. I don't know what i am doing wrong. Sidekiq-cron github page do the same thing.
sidekiq-cron is not targeting the correct version of rufus-scheduler. To make it work again, add this to your Gemfile:
gem 'rufus-scheduler', '~> 3.4.0'
Then run $ bundle install rufus-scheduler.
Summary: After adding logic to save user account data, my code seems to work fine and sometimes all my (many) tests pass. But sometimes they fail seemingly randomly, with /tmp test files not being deleted during testing.
In my hand-rolled Ruby/Sinatra "to do list" program, I added user accounts and can now save data to user files (.yml format) as well as tmp files for people who aren't logged in. Yay!
As far as I can tell, the code works fine. All tests pass...but only sometimes. Sometimes, the tests related to my new file processing methods fail. Here's a sample:
# Running:
....EF..........................
Finished in 3.930466s, 8.1415 runs/s, 53.1744 assertions/s.
1) Error:
ToDoTest#test_post_newtask:
Errno::EACCES: Permission denied # unlink_internal - tmp/1.yml
C:/Users/user/Dropbox/_Programming/Ruby/learning_projects/todo/test/test_todo.rb:404:in `delete'
C:/Users/user/Dropbox/_Programming/Ruby/learning_projects/todo/test/test_todo.rb:404:in `block (2 levels) in teardown'
C:/Users/user/Dropbox/_Programming/Ruby/learning_projects/todo/test/test_todo.rb:404:in `each'
C:/Users/user/Dropbox/_Programming/Ruby/learning_projects/todo/test/test_todo.rb:404:in `block in teardown'
2) Failure:
ToDoTest#test_get_deleted [C:/Users/user/Dropbox/_Programming/Ruby/learning_projects/todo/test/test_todo.rb:167]:
Expected false to be truthy.
32 runs, 209 assertions, 1 failures, 1 errors, 0 skips
rake aborted!
Command failed with status (1): [ruby -I"lib" -I"C:/Ruby23/lib/ruby/gems/2.3.0/gems/rake-10.4.2/lib" "C:/Ruby23/lib/ruby/gems/2.3.0/gems/rake-10.4.2/lib/rake/rake_test_loader.rb" "test/test_task.rb" "test/test_task_store.rb" "test/test_todo.rb" "test/test_todo_helpers.rb" "test/test_users.rb" ]
Tasks: TOP => default => test
(See full trace by running task with --trace)
This is only a sample, because sometimes many more tests fail or have errors. It's weirdly random. I noticed that my tests, which result in a lot /tmp files being made and deleted very rapidly, sometimes failed to delete some files, and as a result some would be left behind. If I reran my tests when there were some undeleted files in /tmp, there would be even more (again, random) errors.
One common error I saw, which I never saw before adding the new file processing commands, is this one: Errno::EACCES: Permission denied # unlink_internal. I looked this up on SO but there seems to be only (irrelevant-seeming) Rails stuff. This is a Sinatra program running on Windows. So could I replicate the tests in my Ubuntu VM? Yes I could. Precisely the same sort of error pattern.
Anyway, I suspected that system commands were not finishing before execution continued. But apparently not. I tried putting "sleep 2" after all my system commands, and I still got a random failing test and cruft left in /tmp. I also tried using threads, which I have never used before, like this:
delr = Thread.new do
File.delete(#store.path) # seems to help to add this here...
end
delr.join
But that didn't help.
One other thing...I'm teaching myself and this is probably not the way it's supposed to be done, but...all of my get methods are preceded by a check of my session[:id] variable to see if the user is logged in, and to see if the correct datafile is loaded. I don't know if that's relevant but it might be.
Any ideas on what the problem could be or how to fix it?
I was happily following this advice on how to run a pry debugger inside my Phoenix controller tests:
require IEx in the target file
add IEx.pry to the desired line
run the tests inside IEx: iex -S mix test --trace
But after a few seconds this error always appeared:
16:51:08.108 [error] Postgrex.Protocol (#PID<0.250.0>) disconnected:
** (DBConnection.ConnectionError) owner #PID<0.384.0> timed out because
it owned the connection for longer than 15000ms
As the message says, the database connection appears to time out at this point and any commands that invoke the database connection will error out with a DBConnection.OwnershipError. How do I tell my database connection not to time out so I can debug my tests in peace?
The Ecto.Adapters.SQL.Sandbox FAQ mentions this issue and explains that you can add the :ownership_timeout setting to your Repo config to specify how long db connections should stay open before timing out. I set mine to 10 minutes (test environment only) so I never have to think about it again:
# config.test.exs
config :rumbl, Rumbl.Repo,
# ...other settings...
ownership_timeout: 10 * 60 * 1000 # long timeout so pry sessions don't break
As expected, I can now fool around in pry for 10 minutes before seeing that error.
I have installed foreman-1.2 with puppet, after installation i have registered my puppet to smart-proxy on foreman.
when i run following command
[root#puppet ~]# puppet agent -t
Warning: Unable to fetch my node definition, but the agent run will continue:
Warning: Error 400 on SERVER: Failed to find puppet.example.com via exec: Execution of '/etc/puppet/node.rb puppet.example.com' returned 1: --- false
Info: Retrieving plugin
Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Failed when searching for node puppet.example.com: Failed to find puppet.example.com via exec: Execution of '/etc/puppet/node.rb puppet.example.com' returned 1: --- false
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run
I tried following
[root#puppet ~]# /etc/puppet/node.rb puppet.example.com
--- false
Error retrieving node puppet.example.com: Net::HTTPNotFound
foreman.log debug
Started GET "/node/puppet.example.com?format=yml" for 10.101.20.15 at 2014-03-25 21:01:47 -0400
Processing by HostsController#externalNodes as YML
Parameters: {"name"=>"puppet.example.com"}
Setting Load (1.3ms) SELECT `settings`.* FROM `settings` WHERE `settings`.`name` = 'restrict_registered_puppetmasters' ORDER BY name LIMIT 1
Setting Load (0.3ms) SELECT `settings`.* FROM `settings` WHERE `settings`.`name` = 'require_ssl_puppetmasters' ORDER BY name LIMIT 1
SmartProxy Load (0.5ms) SELECT `smart_proxies`.* FROM `smart_proxies` INNER JOIN `features_smart_proxies` ON `features_smart_proxies`.`smart_proxy_id` = `smart_proxies`.`id` INNER JOIN `features` ON `features`.`id` = `features_smart_proxies`.`feature_id` WHERE `features`.`name` = 'Puppet' ORDER BY smart_proxies.name
Setting Load (0.3ms) SELECT `settings`.* FROM `settings` WHERE `settings`.`name` = 'trusted_puppetmaster_hosts' ORDER BY name LIMIT 1
Verifying request from ["puppet.example.com"] against ["puppet.example.com"]
User Load (0.4ms) SELECT `users`.* FROM `users` WHERE `users`.`login` = 'admin' LIMIT 1
Setting current user thread-local variable to admin
Host::Managed Load (0.7ms) SELECT `hosts`.* FROM `hosts` WHERE `hosts`.`type` IN ('Host::Managed') AND `hosts`.`certname` = 'puppet.example.com' LIMIT 1
Host::Managed Load (0.6ms) SELECT `hosts`.* FROM `hosts` WHERE `hosts`.`type` IN ('Host::Managed') AND `hosts`.`name` = 'puppet.example.com' LIMIT 1
Completed 404 Not Found in 25ms (ActiveRecord: 4.1ms)
Am i missing something? do i need to create host first on foreman GUI? I don't understand concept of node.rb
First you should check the contents of node.rb. There are a number of variables that need to be set for it to work. It looks like this hasn't been done because the "Net::HTTPNotFound" says it can't find your Foreman server.
Second, yes and no -- the host needs to be defined in Froreman first. If the host doesn't exist in Foreman yet Foreman "may" create it -- it really depends on how you've set up Foreman.
If memory serves properly, I believe a non-existent host will be created when the facts are uploaded by node.rb (if that is enabled). If you're just running it from the command line, then no facts are being uploaded and the host isn't being created.
For your testing, ensure the host is created in Foreman. Then test node.rb (after you check that the vars in it are set properly).
EDIT:
You're last question: node.rb's main function is to get the yaml formated config for a server and hand it to puppet. Secondary it also functions to upload facts from the server to Foreman -- which can be used in classifying the server in Foreman.
Basically you have to make sure that the master and the agent are familiar with each other (either via /etc/hosts or dns). This error is usually raised when the master can not resolve the agent's name (e.g puppet.example.com)
I am getting following error while running a workflow in informatica.
Session task instance [worklet.session] : [TM_6775 The master DTM process was unable to connect to the master service process to update the session status with the following message: error message [ERROR: The session run for [Session task instance [worklet.session]] and [ folder id = 206, workflow id = 16042, workflow run id = 65095209, worklet run id = 65095337, task instance id = 13272 ] is not yet registered with this service process.] and error code [1417].]
This error comes randomly for many other sessions, when they are ran through workflow as a whole. However if I "start task" that failed task next time, it runs successfully.
Any help is much appreciated.
Just an idea to try if you use versioning. Check that everthing is checked in correctly. If the mapping, worflow or worklet is checked out then you and informatica will run different versions wich may cause the behaivour to differ when you start it manually.
Infromatica will allways use the checked in version and you will allways use the checked out version.