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: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>