I am trying to get my sidekiq server and client up and running (using Foreman), but whenever it gets to:
bundle exec sidekiq
The following results:
no implicit conversion of Pathname into String
Just like that, without Type Error preceding it - obviously the stack trace followed (will post if it will help). It says that the problem is in active_support/dependencies.rb (version 5.0.0.1) in the require method. Earlier in the stack trace it gets to boot_system in sidekiq's cli.rb (version 4.1.2). I am not sure whether this is a known issue with sidekiq or whether I am missing some configuration (I have read through a good number of tutorials on this which include thorough discussion of considerations to make in regarding sidekiq, puma and redis' configs, but to no avail). I am running Ruby 2.3.1 and Rails 5.0.0.1
The sidekiq.yml file includes (I got the error before this file and including it did not solve the issue):
development:
:concurrency: 5
production:
:concurrency: 20
:queues:
- default
Also, I am really new to posting on stackoverflow (but have made frequent use of it in the past). Any guidance would be great!
So I did manage to get my sidekiq up and running with redis. My problem was with one of the worker scripts which had an error in it... It was picking it up in a directory other than app/workers (I placed it in app/temp while I was debugging) - only saw it now in the stack trace: obviously missed it earlier due to looking at a screen too long (the classics). Still was weird that the error message was missing Type Error though.
Related
I have a Rails app running version 6.1.1 and currently, we use Ruby 2.7.2
While trying to upgrade to Ruby 3, I'm facing an interesting issue: some code apparently is blocking the main thread. When I try to boot the server or run the tests, the console stuck and I can't even stop the process, I have to kill it.
I tracked it down to one gem called valvat, used to validate EU VAT numbers. I opened an issue on its Github repo but the maintainer couldn't reproduce even using the same Gemfile.lock I have, which lead me to believe that it might not be just the gem, gotta be something else in my code.
This is what happens when I try to boot the server:
=> Booting Puma
=> Rails 6.1.1 application starting in development
=> Run `bin/rails server --help` for more startup options
^C^C^C
as one can see, I can't even stop it, the thread is now hanging and I can't tell exactly by whom.
I tried to run the specs with -b -w to see what I can see but got the same error: the thread hangs and the warnings I get from Ruby are just generic ones like method already defined or something like that.
This is the last output from the console while running specs with -b -w before the thread hangs:
/Users/luiz/rails_dev/app/config/initializers/logging_rails.rb:18: warning: method redefined; discarding old tag_logger
/Users/luiz/.rbenv/versions/3.0.0/lib/ruby/gems/3.0.0/gems/activejob-6.1.1/lib/active_job/logging.rb:19: warning: previous definition of tag_logger was here
thing is, I also get these warnings when I remove the gem and run this command though the specs run without issues then.
Is there a way to track this down to whatever is causing the thread to hang?
If you have no error message, it's hard to understand where exactly your application hangs.
As the developer cannot reproduce with your Gemfile.lock, it's possible that one of your config file or initializers is the culprit. You could create a new blank application with the same Gemfile, add your config and initializers files one by one, and test each time if the server runs until you find which one is causing the freeze.
Test also your application with another Ruby version (are you using rbenv or RVM?)
Also check your syslog, as valvat calls a web service you may find connection errors there. Check this doc on how to access your syslog: https://www.howtogeek.com/356942/how-to-view-the-system-log-on-a-mac/
Every time I spin up my Rails App locally, none of the CSS shows up. The debugger in the browser shows a get request for all of the asset files with fingerprinting, but they all fail since the files can't be found. Here is what one of those requests looks like:
GET http://localhost:3000/assets/announcements.self-e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.css?body=1
In the Rails Server Console, I get a Rack App Error, as well as a NoMethodError for the undefined method 'Silence'. Here is what one of those errors looks like:
2017-01-08 17:24:49 -0800: Rack app error handling request { GET /assets/normalize.self-cadbbf81015902777c37852b3ea54398335fd421c6c76891c077ec5954211bb4.css }
NoMethodError: undefined method 'silence' for #<Logger:0x007fe1062c1c78
Both Error logs (Browser Console and Localhost Server Console) contain multiple renditions of the same error, all pointing to Assets (*.js, and *.css).
I have searched through countless StackOverflow Posts but to no avail. This also for some reason only affects this one application; all my other Rails applications run fine. Here are my specifications:
Rails Version: 5.0.1
Ruby Version: 2.3.1p112
Things I have tried:
assets:clean, assets:precompile, rm -rf /tmp and /public/assets directpories, all of the previous prepended with the development environment, recloning the repository from github and bundle installing.
I know this is an old question, but stumbled across this while trying to fix the same problem.
I found as well as Ryan Bigg's answer I needed to comment out the following line in development.rb to stop Sprockets from bombing in Rails 5.2.2:
# Suppress logger output for asset requests.
# config.assets.quiet = true
It looks like you're running into this issue: https://github.com/rails/sprockets-rails/issues/376.
Where you've made this configuration change you should be using ActiveSupport::Logger instead. Where you have Logger.new, use ActiveSupport::Logger instead.
check The Sprockets 4 Manifest in rails 5
http://eileencodes.com/posts/the-sprockets-4-manifest/
It might help you.
I keep getting errors reported to Honeybadger that various mailer fail from being unable to find the template like: ActionView::MissingTemplate: Missing template user_mailer/send_invitation with "mailer". Searched in: * "user_mailer". I have found a way I can reliably reproduce it is by restarting the Unicorn workers or ssh'ing into the server and using the Rails console to manually trigger the email. To make things more interesting, it only throws this error if I use deliver_later but not if I use deliver_now. Obviously I want to deliver emails asynchronously, so using deliver_now isn't really an option unless I make my own job that trigger the email manually, but that doesn't seem optimal.
Sidekiq.yml
production:
:concurrency: 10
:queues:
- default
- mailers
- elasticsearch
- searchkick
It still delivers the emails on the second attempt, so I'm not sure if this has to do with some loading of Sidekiq or something. Any help is greatly appreciated.
Using Rails 5.0.0, Sidekiq 4.1.4, and ActiveJob 5.0.0.
it tells that there's no required file, simply create the file:
app/views/user_mailer/send_invitation.html.erb
It turns out that when I upgraded Sidekiq from 4.0.4 to 4.1.4 it didn't kill my old process so it was hanging around undetected by monit and still plucking jobs from redis. Killed the old processes and it is all fine now. Thanks for every ones feedback.
I am running a Rails 4.2.3 application that runs in production when deployed and with environment variables set through Heroku. However, my development and test environments suddenly began failing with this error:
DEPRECATION WARNING: You didn't set `secret_key_base`. Read the upgrade documentation to learn more about this new config option. (called from service at /Users/Benjamin/.rvm/rubies/ruby-2.2.1/lib/ruby/2.2.0/webrick/httpserver.rb:138)
According to everything I've found on StackOverflow and elsewhere, this probably has something to do with my secrets.yml file:
development:
secret_key_base: LONG-KEY
test:
secret_key_base: LONG-KEY
I have tried resetting these keys with rake secret to no avail. I have other environment variables set in secrets.yml that are being correctly set, but when I run Rails.application.secrets.secret_key_base from console I keep getting nil.
Any help would be much appreciated.
When you say you have tried resetting them with rake secret what do you mean? You copied and pasted the keys from the console into secrets.yml into the correct spots and saved? As long as both keys are in there, are at least 30 chars long (they would be 128 chars long in your case having u used rake secret) you should be all set. I assume your secrets.yml file is located in config/.
Also, the deprecation warning is a warning not an error. As long as the keys are in the secrets.yml you should not have to do anything else. Running rake secret and replacing the keys with new ones is unnecessary, as long as you have keys there (of at least 30 chars) it doesn't matter what the keys are.
Hope this helps. If you are still having difficulty, post the runtime error and hopefully it will provide more insight into what is wrong.
This is not likely your problem, but I have spent hours on this issue, which was also giving me the same error message of 'secret_key_base' not being set for the production rails server start.
I am running Rails ver. 4.2.5.1, Ruby ver. 2.3.0, WEBrick 1.3.1, with the development and production server running experimentally on a CentOS 6.6 Linux box. My error was a complete newbie thing..
I had followed the steps to configure a SECRET_BASE_KEY for production, and am using the secrets.yml file, with the environment var being used to set the key, as per Rails docs and other Stackoverflow reports. But I was starting my production server with:
bin/rails server --binding=0.0.0.0 -p 3000 -e=production
which is wrong. The short form "-e" parameter has no equals sign. But the error I got was because the code in the secrets.yml file was looking for something called "=production:", and the label is "production:". The correct expression to start the server in production mode is of course:
bin/rails server --binding=0.0.0.0 -p 3000 -e production
The other clue, was that the server was reporting "config.eager_load" was set to nil, when in fact it was configured to be set in the ../config/environments/production.rb file.
Hope this helps someone. I am a complete newbie at Rails+Ruby, but I finally have a testbed server running in a production mode, with the various config settings applied as expected.
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