Sometimes occur "Segmentation fault". #851
Comments
|
Sounds like it's related to this #441. I see you're using Unicorn – could you provide your Unicorn config? |
|
This issue is also related #504 |
|
Thank you for the information that this is a problem with Ruby 2.5 and elastic-apm. Below is my unicorn configuration.
instance_eval File.read(File.join(__dir__, 'common.rb'))
_working_path = '/srv/app/current'
worker_processes 28
working_directory _working_path
before_exec do |server|
ENV['BUNDLE_GEMFILE'] = File.join(_working_path, 'Gemfile')
end
pid "tmp/pids/unicorn.pid"
stderr_path "log/unicorn.log"
stdout_path "log/unicorn.log"
timeout 60
# combine Ruby 2.0.0dev or REE with "preload_app true" for memory savings
# http://rubyenterpriseedition.com/faq.html#adapt_apps_for_cow
preload_app true
GC.respond_to?(:copy_on_write_friendly=) and
GC.copy_on_write_friendly = true
# Enable this flag to have unicorn test client connections by writing the
# beginning of the HTTP headers before calling the application. This
# prevents calling the application for connections that have disconnected
# while queued. This is only guaranteed to detect clients on the same
# host unicorn runs on, and unlikely to detect disconnects even on a
# fast LAN.
check_client_connection false
before_fork do |server, worker|
# the following is highly recomended for Rails + "preload_app true"
# as there's no need for the master process to hold a connection
if defined?(ActiveRecord::Base)
ActiveRecord::Base.connection.disconnect!
ActiveRecord::Base.clear_all_replica_connections!
end
# The following is only recommended for memory/DB-constrained
# installations. It is not needed if your system can house
# twice as many worker_processes as you have configured.
#
# This allows a new master process to incrementally
# phase out the old master process with SIGTTOU to avoid a
# thundering herd (especially in the "preload_app false" case)
# when doing a transparent upgrade. The last worker spawned
# will then kill off the old master process with a SIGQUIT.
old_pid = "#{server.config[:pid]}.oldbin"
if old_pid != server.pid
begin
sig = (worker.nr + 1) >= server.worker_processes ? :QUIT : :TTOU
Process.kill(sig, File.read(old_pid).to_i)
rescue Errno::ENOENT, Errno::ESRCH
end
end
#
# Throttle the master from forking too quickly by sleeping. Due
# to the implementation of standard Unix signal handlers, this
# helps (but does not completely) prevent identical, repeated signals
# from being lost when the receiving process is busy.
sleep 1
end
after_fork do |server, worker|
# per-process listener ports for debugging/admin/migrations
# addr = "127.0.0.1:#{9293 + worker.nr}"
# server.listen(addr, :tries => -1, :delay => 5, :tcp_nopush => true)
# the following is *required* for Rails + "preload_app true",
defined?(ActiveRecord::Base) and
ActiveRecord::Base.establish_connection and
ActiveRecord::Base.establish_fresh_connection
# if preload_app is true, then you may also want to check and
# restart any other shared sockets/descriptors such as Memcached,
# and Redis. TokyoCabinet file handles are safe to reuse
# between any number of forked children (assuming your kernel
# correctly implements pread()/pwrite() system calls)
end |
|
Try putting a |
|
Thanks mikker. I'm trying it, and looks good working now 😃 but I think, it is not cause of SEGV. |
|
@ota-akira Glad to hear it's working now! |
|
Just a note for anyone else looking here: I have a similar forking Unicorn setup and adding |
|
thanks for all. (and sorry I'm late response.) @estolfo @Matt-Yorkley ElasticAPM.restart.tap do |agent|
agent.instrumenter.subscriber = ElasticAPM::Subscriber.new(agent) if agent.present?
endusually attach to apm-agent-ruby/lib/elastic_apm/rails.rb Lines 46 to 48 in dead774 |
|
@Matt-Yorkley and @ota-akira As of version 3.7.0 of the agent, forking is detected automatically and the agent is restarted. So it shouldn't be necessary to restart the agent in an @ota-akira If you've had to set the subscriber explicitly when it is restarted, that sounds like a bug that we should fix. When you say the traces are messed up, what do you mean? |
|
@estolfo "Traces are messed up" means that transaction information cannot be logged. we think this code replaces all it sounds like bug, but we think "bottom cause is using Ruby 2.5". thank you. |
|
@ota-akira is this still an issue or can we close it? |
Describe the bug
Hi! I'm testing my application with elastic apm.
but I faced to SEGV on my application, it occurred from elastic-apm gem.
It not reproduce, sometimes occurred.
NOTE:
my application,
APM Server not responding in time, terminating requesterror is acceptable, but SEGV is not acceptable.Steps to reproduce
Expected behavior
Environment
I have 15 application servers, but apm server is 1 server. (because currently testing)
Additional context
Add any other context about the problem here.
Click to expand
Click to expand
The text was updated successfully, but these errors were encountered: