I'm facing same problem described here: why-rails-fails-with-ruby-exe-has-encountered-a-problem-and-needs-to-close. that is ruby get crashed with following error:
ruby.exe has encountered a problem and needs to close. We are sorry for the inconvenience.
I'm asking this to add some details on it as that question was not asked by me I am not able to add information in it. So this is not duplicate.
Ruby crashes eventually no matter how I run it (in development or in production), but it seems to crash more often in production mode. Sometimes it will crash when I hold down the F5 key, but sometimes I have to hold and release it intermittently for a minute or two. It appears to be very dependent on timing, but I can usually make it crash in less than 60 seconds.
When I refresh the GET request is sent for 3 times as follows:
Started GET "/app/page" for 127.0.0.1 at 2011-02-23 10:57:35 +0530
Processing by AppController#page as HTML
Rendered pms/dashboard.html.erb within layouts/application (109.4ms)
Completed 200 OK in 141ms (Views: 140.6ms | ActiveRecord: 0.0ms)
Started GET "/app/page" for 127.0.0.1 at 2011-02-23 10:57:35 +0530
Processing by AppController#page as */*
Rendered pms/dashboard.html.erb within layouts/application (15.6ms)
Completed 200 OK in 187ms (Views: 187.5ms | ActiveRecord: 0.0ms)
Started GET "/app/page" for 127.0.0.1 at 2011-02-23 10:57:35 +0530
Processing by AppController#page as */*
Rendered pms/dashboard.html.erb within layouts/application (15.6ms)
Completed 200 OK in 219ms (Views: 218.7ms | ActiveRecord: 0.0ms)
And if I rapidly refresh the page get following error in one of or all the 3 request:
ERROR Errno:ECONNABORTED: An established connection was aborted by the software in your host machine:
c:/Ruby/lib/1.9.1/webrick/httpresponse.rb:323:in 'write'
c:/Ruby/lib/1.9.1/webrick/httprespose.rb:323:in '<<'
c:/Ruby/lib/1.9.1/webrick/httprespose.rb:323:in '_write_data'
c:/Ruby/lib/1.9.1/webrick/httprespose.rb:295:in 'send_body_string'
c:/Ruby/lib/1.9.1/webrick/httprespose.rb:186:in 'send_body'
c:/Ruby/lib/1.9.1/webrick/httprespose.rb:103:in 'send_response'
c:/Ruby/lib/1.9.1/webrick/httpserver.rb:86:in 'run'
ERROR Errno:ECONNABORTED: An established connection was aborted by the software in your host machine:
c:/Ruby/lib/1.9.1/webrick/httpserver.rb:56:in 'eof?'
c:/Ruby/lib/1.9.1/webrick/httpserver.rb:56:in 'run'
c:/Ruby/lib/1.9.1/webrick/server.rb:183:in 'block in start_thread'
INFO going to shutdown....
INFO WEBrick::HTTPServer#start done
When I started to get this error?
When I added images, css and javascript in my project I started to get this error. I also tried by removing one of this 3 and see who causes the error but every time my ruby.exe get crashed and i see the error:
ruby.exe has encountered a problem and needs to close. We are sorry for the inconvenience.
How can I solve this?
When I start server following is printed on console:
=>Booting WEBrick
=>Rails 3.0.3 application starting in development on http://0.0.0.0:3000
=>Call with -d to detach
=>Ctrl-C to shutdown server
[2011-02-23 10:59:22] INFO WEBrick 1.3.1
[2011-02-23 10:59:22] INFO ruby 1.9.2 (2010-08-18) [i386-mingw32]
[2011-02-23 10:59:22] INFO WEbrick::HTTPServer#start: pid:2448 port=3000
Output of ruby -v
ruby 1.9.2p0 (2010-08-18) [i386-mingw32]
... except the installer is now ALSO the crashing 1.9.2-p290
Workaround:
Add (or change)
config.log_level = :warn
in config/environments/development.rb
(not my solution - found it in another thread)
Running 1.9.2 on windows puts you in a REALLY small minority of users. If you don't have an explicit need for 1.9, I'd use 1.8.7. Specifically, I'd use the package from RailsInstaller: http://railsinstaller.org/
i got the same crashes on windows 7 with 1.9.2-p290. someone said to clear development.log file. i can't believe but after deleting my 12mb development.log everything works fine.
it is possible that a native (C) extension is failing and bringing the whole ruby down; in my case it was sql server adapter looping indefinitely/using whole heap; after we traced and fixed the bug in the adapter (https://github.com/rails-sqlserver/tiny_tds/pull/124) it does not fail again
Related
I'm trying to implement a small WEBrick server that ends itself when there are no requests after x number of seconds. However, I'm getting nowhere. My very first attempt at simply exiting after 2 seconds fails. Here's the simple code
that doesn't work.
server = WEBrick::HTTPServer.new(:Port => 8000)
WEBrick::Utils::TimeoutHandler.register(2, Timeout::Error)
server.start
I thought that would simply exit the process after 2 seconds. Here's what actually happens:
[2020-01-19 15:41:10] INFO WEBrick 1.4.2
[2020-01-19 15:41:10] INFO ruby 2.5.1 (2018-03-29) [x86_64-linux-gnu]
[2020-01-19 15:41:10] INFO WEBrick::HTTPServer#start: pid=16622 port=8000
[2020-01-19 15:41:12] ERROR Timeout::Error: execution timeout
/usr/lib/ruby/2.5.0/webrick/server.rb:170:in `select'
And then the process keeps running. I have to ctrl-c to end it.
What's the correct way to shut down a server and end the process after a timeout?
[Note: I "fixed" this problem by creating and using a new gemset. I'm still curious why the problem occurred but it is no longer blocking me.]
[I am aware that there is a similar issue at Deadlock in Ruby join(), but I have tried the timeout parameter suggested there and it does not help. I suspect there is a pry-specific problem not covered there.]
I am getting the error below when running the code below, but only when executed within a pry session. This code has not been changed and has been working fine for quite a while, and I have no idea why it's an issue just now. I am using pry version 0.11.3 on Ruby 2.5.1. Also, this code works fine when pasted into pry; it's not working in my wifi-wand application that launches pry in the context of one of its objects (gem install wifi-wand to install, https://github.com/keithrbennett/wifiwand is the project page).
domains = %w(google.com baidu.com)
puts "Calling dig on domains #{domains}..." if #verbose_mode
threads = domains.map do |domain|
Thread.new do
output = `dig +short #{domain}`
output.length > 0
end
end
threads.each(&:join)
[1] pry(#<WifiWand::CommandLineInterface>)> ci
Calling dig on domains ["google.com", "baidu.com"]...
fatal: No live threads left. Deadlock?
3 threads, 3 sleeps current:0x00007fbd13d0c5a0 main thread:0x00007fbd13d0c5a0
* #<Thread:0x00007fbd14069c20 sleep_forever>
rb_thread_t:0x00007fbd13d0c5a0 native:0x00007fff89c2b380 int:0
/Users/kbennett/work/wifi-wand/lib/wifi-wand/models/base_model.rb:89:in `join'
/Users/kbennett/work/wifi-wand/lib/wifi-wand/models/base_model.rb:89:in `each'
/Users/kbennett/work/wifi-wand/lib/wifi-wand/models/base_model.rb:89:in `block in connected_to_internet?'
/Users/kbennett/work/wifi-wand/lib/wifi-wand/models/base_model.rb:126:in `connected_to_internet?'
/Users/kbennett/work/wifi-wand/lib/wifi-wand/command_line_interface.rb:264:in `cmd_ci'
Strangely, the problem was fixed by uninstalling and reinstalling the awesome_print gem. I have no idea why.
I'm experiencing an unresponsive socket in with my Puma setup after random time. Up to this point I don't have a clue what's causing the issue. I was hoping somebody over here can help we with some answers or point me in the right direction. I'm having the following setup:
I'm using the official docker ruby-2.2.3-slim image together with the latest puma release 2.15.3, I've also installed Nginx as a reverse proxy. But I'm already sure Nginx isn't the problem over here because and I've tried to verify if the socket was working using this script. And the socket wasn't working, I got a timeout over there as well so I could ignore Nginx.
This is a testing environment so the server isn't experiencing any extreme load, I've also check memory consumption it has still several GB's of free space so that couldn't be the issue either.
What triggered me to look at the puma socket was the error message I got in my Nginx error logging:
upstream timed out (110: Connection timed out) while reading response header from upstream
Also I couldn't find anything in the logs of puma indicating what is going wrong, over here are my puma setup:
threads 0, 16
app_dir = ENV.fetch('APP_HOME')
environment ENV['RAILS_ENV']
daemonize
bind "unix://#{app_dir}/sockets/puma.sock"
stdout_redirect "#{app_dir}/log/puma.stdout.log", "#{app_dir}/log/puma.stderr.log", true
pidfile "#{app_dir}/pids/puma.pid"
state_path "#{app_dir}/pids/puma.state"
activate_control_app
on_worker_boot do
require 'active_record'
ActiveRecord::Base.connection.disconnect! rescue ActiveRecord::ConnectionNotEstablished
ActiveRecord::Base.establish_connection(YAML.load_file("#{app_dir}/config/database.yml")[ENV['RAILS_ENV']])
end
And this it the output in my puma state file:
---
pid: 43
config: !ruby/object:Puma::Configuration
cli_options:
conf:
options:
:min_threads: 0
:max_threads: 16
:quiet: false
:debug: false
:binds:
- unix:///APP/sockets/puma.sock
:workers: 1
:daemon: true
:mode: :http
:before_fork: []
:worker_timeout: 60
:worker_boot_timeout: 60
:worker_shutdown_timeout: 30
:environment: staging
:redirect_stdout: "/APP/log/puma.stdout.log"
:redirect_stderr: "/APP/log/puma.stderr.log"
:redirect_append: true
:pidfile: "/APP/pids/puma.pid"
:state: "/APP/pids/puma.state"
:control_url: unix:///tmp/puma-status-1449260516541-37
:config_file: config/puma.rb
:control_url_temp: "/tmp/puma-status-1449260516541-37"
:control_auth_token: cda8879717be7a645ea323d931b88d4b
:tag: APP
The application itself is a Rails app on the latest version 4.2.5, it's deployed on GCE (Google Container Engine).
If somebody could give me some pointer's on how to debug this any further would be very much appreciated. Because now I don't see any output anywhere which could help me any further.
EDIT
I replaced the unix socket with tcp connection to Puma with the same result, still hangs after x time
I'd start with:
How many requests get processed successfully per instance of puma?
Make sure you log the beginning and end of each request with the thread id of the thread executing it, what do you see?
Not knowing more about your application, I'd say it's likely the threads get stuck doing some long/blocking calls without timeouts or spinning on some computation until the whole thread pool gets depleted.
We'll see.
I finally found out why my application was behaving the way it was.
After trying to use a tcp connection and switching to Unicorn I start looking into other possible sources.
That's when I thought maybe my connection to Google Cloud SQL could be the problem. Once I read the faq of Cloud SQL, they mentioned that you have to tweak you Compute instances to ensure they keep open your DB connection. So I performed the next steps they recommend and that solved the problem for me, I added them just in case:
# Display the current tcp_keepalive_time value.
$ cat /proc/sys/net/ipv4/tcp_keepalive_time
# Set tcp_keepalive_time to 60 seconds and make it permanent across reboots.
$ echo 'net.ipv4.tcp_keepalive_time = 60' | sudo tee -a /etc/sysctl.conf
# Apply the change.
$ sudo /sbin/sysctl --load=/etc/sysctl.conf
# Display the tcp_keepalive_time value to verify the change was applied.
$ cat /proc/sys/net/ipv4/tcp_keepalive_time
Setup a new angular project under linux. Committed it to git and cloned it to windows. Using bower and npm, I managed to get everything loaded, except, I have this one error (only on windows)
A recursive grep for ../time/convert in the project shows me:
./node_modules/grunt-contrib-imagemin/node_modules/gifsicle/node_modules/bin-wrapper/node_modules/mout/date/diff.js:var convert = require('../time/convert');
./node_modules/grunt-contrib-imagemin/node_modules/gifsicle/node_modules/bin-wrapper/node_modules/mout/src/date/diff.js:define(['./totalDaysInMonth', './totalDaysInYear', '../time/convert'], function(totalDaysInMonth, totalDaysInYear, convert){
./node_modules/grunt-contrib-imagemin/node_modules/optipng-bin/node_modules/bin-wrapper/node_modules/mout/date/diff.js:var convert = require('../time/convert');
./node_modules/grunt-contrib-imagemin/node_modules/pngquant-bin/node_modules/bin-wrapper/node_modules/mout/date/diff.js:var convert = require('../time/convert');
./node_modules/grunt-contrib-imagemin/node_modules/pngquant-bin/node_modules/bin-wrapper/node_modules/mout/src/date/diff.js:define(['./totalDaysInMonth', './totalDaysInYear', '../time/conve
but ls -l shows:
$ ls ./node_modules/grunt-contrib-imagemin/node_modules/gifsicle/node_modules/bin-wrapper/node_modules/mout/time
convert.js now.js parseMs.js toTimeString.js
Which says that convert.js is actually there. Being new to grunt and angular, I'm puzzled where this could be coming from and how to troubleshoot it.
After this I end up getting stuck here:
Running "karma:unit" (karma) task
INFO [karma]: Karma v0.10.4 server started at http://localhost:8080/
INFO [launcher]: Starting browser Chrome
WARN [watcher]: Pattern ".../test/mock/**/*.js" does not match any file
WARN [launcher]: Chrome have not captured in 60000 ms, killing.
INFO [launcher]: Trying to start Chrome again.
WARN [launcher]: Chrome have not captured in 60000 ms, killing.
INFO [launcher]: Trying to start Chrome again.
Wondering if angular work using grunt is just not possible on Windows....
My solution was to quit using windows. Moved dev work to linux, and no more crazy problems like this. Oh, and my machine now seems a good deal faster too.
I upgraded to ruby 1.9.3 this morning, kept the same version of Rails 3.0.8 and installed / updated passenger-3.0.9. Everything seems to run OK when I launch the application, until I try and login (make a database connection), I get a 502 Bad Gateway and the following error message in the console:
[NOTE] You may have encountered a bug in the Ruby interpreter or
extension libraries. Bug reports are welcome. For details:
http://www.ruby-lang.org/bugreport.html
2011/10/31 08:37:22 [error] 6201#0: *6 upstream prematurely closed
connection while reading response header from upstream, client:
127.0.0.1, server: _, request: "GET /status HTTP/1.1", upstream: "passenger:unix:/passenger_helper_server:", host: "0.0.0.0:3000"
Any ideas? Thank you
This has been discussed in the last week on the Passenger mailing list.
Looks like it's still an open bug:
http://code.google.com/p/phusion-passenger/issues/detail?id=714
Only solution I know of is to downgrade to 1.9.2-p290 until it's fixed.