From: Eric Wong Date: 2018-07-20T10:14:42+00:00 Subject: [ruby-core:88015] Re: [Ruby trunk Feature#5446] at_fork callback API eregontp@gmail.com wrote: > IMHO, this is is still very much needed for cases using plain fork(). > The default close-on-exec behavior is irrelevant for fork() without exec() and does not help. Agreed. > Inheriting, e.g., a database connection in such a case is > extremely harmful (data corruption or leaking sensitive data) > and a common pitfall. It's been a known problem for decades, now (at least since the days of mod_perl + DBI on Apache 1.x); and AFAIK there's no data leaks from it. Anybody who makes that mistake would likely raise/crash/burn long before seeing, much less leaking sensitive data. > Having a nice at_fork hook would allow to safely disconnect the database in each forked process to avoid accidental file descriptor sharing between forks. > > Sequel: > https://github.com/jeremyevans/sequel/issues/691 I agree with Jeremy on this; it will likely cause new problems and surprises if libraries use it. > Passenger has PhusionPassenger.on_event(:starting_worker_process). > They give the example of memcached and by default use it to reestablish ActiveRecord connections: > https://www.phusionpassenger.com/library/indepth/ruby/spawn_methods/#unintentional-file-descriptor-sharing > > Puma has before_fork: > https://github.com/puma/puma/pull/754/files Exactly my point, everything relevant which forks has documented and supported means to disconnect/restart connections. > @normalperson Don't you think this deserves to be in core? Not anymore. > I would guess all of these do not work if rb_fork() is called. > What more motivation do we need? > Wait that a major incident happen due to unintentional fd > sharing because database libraries cannot protect themselves > from fork()? Again, this is a known problem with known workarounds for decades, now. I expect nobody has been able to get close to production or dealing with important data with such a broken setup. Unsubscribe: