ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
From: hello@jessicastokes.net
To: ruby-core@ruby-lang.org
Subject: [ruby-core:84354] [Ruby trunk Bug#14009] macOS High Sierra and “fork” compatibility
Date: Wed, 20 Dec 2017 01:45:16 +0000 (UTC)	[thread overview]
Message-ID: <redmine.journal-68535.20171220014515.84a7a37deccca804@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-14009.20171012181802@ruby-lang.org

Issue #14009 has been updated by ticky (Jessica Stokes).


Just for reference, people seem confused about the fact this patch hasn’t made it into Ruby 2.4.3; as far as I can tell it will only appear in version 2.5. Is a backport forthcoming or is the idea for people who need High Sierra compatibility to simply move to 2.5?

https://github.com/puma/puma/issues/1421#issuecomment-352083160

----------------------------------------
Bug #14009: macOS High Sierra and “fork” compatibility
https://bugs.ruby-lang.org/issues/14009#change-68535

* Author: ticky (Jessica Stokes)
* Status: Closed
* Priority: Normal
* Assignee: 
* Target version: 
* ruby -v: ruby 2.4.2p198 (2017-09-14 revision 59899) [x86_64-darwin17]
* Backport: 2.3: UNKNOWN, 2.4: REQUIRED
----------------------------------------
This was originally discussed on the issue tracker for Puma (https://github.com/puma/puma/issues/1421), however, it is possible that it would make more sense for inclusion in the Ruby implementation itself.

macOS High Sierra has changed the behaviour of the fork syscall such that initialising Objective-C APIs in forked processes are treated as errors. (see http://sealiesoftware.com/blog/archive/2017/6/5/Objective-C_and_fork_in_macOS_1013.html for more details)

This means that many applications which use forking to process concurrently will forcibly crash if the forked process calls out to any Objective-C library when Objective-C was not already initialised in the host process. This includes Puma, Unicorn, iodine and Passenger.

A workaround I proposed for Puma was to implicitly load the Objective-C runtime before performing any forks (https://github.com/puma/puma/issues/1421#issuecomment-332650703). This causes forked processes using other Objective-C APIs to not crash.

The workaround (specific to Puma’s DSL) was:

~~~ ruby
# Work around macOS 10.13 and later being very picky about
# `fork` usage and interactions with Objective-C code
# see: <https://github.com/puma/puma/issues/1421>
if /darwin/ =~ RUBY_PLATFORM
  before_fork do
    require 'fiddle'
    # Dynamically load Foundation.framework, ~implicitly~ initialising
    # the Objective-C runtime before any forking happens in Puma
    Fiddle.dlopen '/System/Library/Frameworks/Foundation.framework/Foundation'
  end
end
~~~

A similar fix has now been included in Passenger (https://github.com/phusion/passenger/blob/2a55a84e5de721d8bd806a8fea0bcedf27583c29/src/ruby_supportlib/phusion_passenger/loader_shared_helpers.rb#L84-L105).

It was, however, proposed that it might make more sense for Ruby on macOS High Sierra and onward to implicitly initialise the Objective-C framework itself, so that forked processes work roughly as expected even if they intend to use Objective-C APIs.

I understand that this is a heavy-handed move, but it seems to me that this relatively common technique will remain broken in Ruby unless everyone deploys a workaround (iodine has already expressed disinterest in doing so) or Ruby adopts one at the higher level.

This issue is also applicable to all Ruby versions which support fork and run on macOS High Sierra.

Thank you for your time. :)



-- 
https://bugs.ruby-lang.org/

  parent reply	other threads:[~2017-12-20  1:45 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <redmine.issue-14009.20171012181802@ruby-lang.org>
2017-10-12 18:18 ` [ruby-core:83239] [Ruby trunk Bug#14009] macOS High Sierra and “fork” compatibility hello
2017-10-12 20:18 ` [ruby-core:83243] " hongli
2017-10-13  0:58 ` [ruby-core:83250] " bo
2017-10-13  2:23 ` [ruby-core:83255] [Ruby trunk Bug#14009][Feedback] " nobu
2017-10-13  2:35 ` [ruby-core:83256] [Ruby trunk Bug#14009] " bo
2017-10-13  6:02 ` [ruby-core:83260] " hongli
2017-10-13  7:04 ` [ruby-core:83261] " nobu
2017-10-13 14:55 ` [ruby-core:83265] " bo
2017-10-13 17:18 ` [ruby-core:83267] " hello
2017-10-13 17:30 ` [ruby-core:83268] " hello
2017-10-13 19:24 ` [ruby-core:83270] " mperham
2017-10-13 20:49 ` [ruby-core:83271] " hongli
2017-10-13 21:34 ` [ruby-core:83273] " hello
2017-10-14  1:54 ` [ruby-core:83275] " nobu
2017-10-15  9:50 ` [ruby-core:83293] " nobu
2017-10-16  1:01 ` [ruby-core:83303] " bo
2017-10-16  6:44 ` [ruby-core:83310] " nobu
2017-10-19 15:51 ` [ruby-core:83398] " hi
2017-12-20  1:45 ` hello [this message]
2017-12-20  3:24 ` [ruby-core:84355] " nagachika00
2017-12-20  3:50 ` [ruby-core:84356] " hello
2017-12-20 11:55 ` [ruby-core:84358] " nagachika00
2018-01-31 13:58 ` [ruby-core:85309] " usa
2018-07-30 16:36 ` [ruby-core:88210] " quaeler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.ruby-lang.org/en/community/mailing-lists/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=redmine.journal-68535.20171220014515.84a7a37deccca804@ruby-lang.org \
    --to=ruby-core@ruby-lang.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).