hyperion-rb 2.16.0 → 2.16.2

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: d599cad6595983a3aef241b7e5895b613c6275e44e8f05925f29c82fba99072c
-  data.tar.gz: c733f8b8e0f2d7de93a5bed82d4cea1331bbafafde347334cf08bbb00f8c1474
+  metadata.gz: 85ee19dc8b680c83c849964653ce228ebb94cd65a430f43ed13653ba36f06190
+  data.tar.gz: 4a02a074020c814d3036099d9ff996dd7098e704b03c4484e8a86e8320b60c65
 SHA512:
-  metadata.gz: 8311ce71399125875a3bab4499244801dfeac405512a6a3339762dc075e495a86e961f1135eb33ec8ac30c7d2e0bb46d0951a53ba144f42a1a40fce855889a74
-  data.tar.gz: c1eee7b3bdc928bdf328223abf54c80d5a1d9742a770968063659a98943a04e7c0f3b5530c4b5e5fef62847ccf29d6ddafb4cf8e7b4ee187968a82c27ad0f8b5
+  metadata.gz: b614b52474052c37ba35d8d5bb633227b4b05112c617e71893e3a8c28d6d10f4ca406478a024238a841bc9aed5cc86df1ebcca5b9c8b9d21ab315ddfc8dcf996
+  data.tar.gz: aef147c323a1ca872d6e8467e15ff50a58fe8ae81a926b7fb87362736d5072824b785bdf682341fa4da858c7887aada193199a91f320ad3b88cafe55ee267ae5

data/CHANGELOG.md

@@ -1,5 +1,99 @@
 # Changelog
 
+## 2.16.2 — 2026-05-04
+
+### 2.16.2-A — macOS Obj-C fork-safety: re-exec, not just ENV write
+
+**Why.** 2.16.1's `ENV['OBJC_DISABLE_INITIALIZE_FORK_SAFETY'] ||= 'YES'`
+in `bin/hyperion` and `lib/hyperion.rb` did not actually stop the
+crash. The Obj-C runtime caches that env var's value at **dyld init**
+— before any Ruby code runs. By the time `bin/hyperion`'s first
+line executes, the runtime has already decided whether the post-fork
+check fires. Setting the var from Ruby is observable to `ENV.fetch`
+and inherited by `Process.fork` children via the kernel's env
+duplication, but the Obj-C runtime's own check ignores the late
+write. Workers continued to crash on `+[NSCharacterSet initialize]`
+in fork children after a 2.16.1 master spawned them.
+
+**What 2.16.2-A ships.** `bin/hyperion` now **re-execs itself** with
+the env var set when launched on `darwin` without it:
+
+```ruby
+if RUBY_PLATFORM.include?('darwin') && ENV['OBJC_DISABLE_INITIALIZE_FORK_SAFETY'].nil?
+  ENV['OBJC_DISABLE_INITIALIZE_FORK_SAFETY'] = 'YES'
+  exec(RbConfig.ruby, __FILE__, *ARGV)
+end
+```
+
+`exec` replaces the current process image; dyld of the new image
+reads `OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES` from the inherited
+environment and the runtime's fork-safety check honours it for the
+master and every worker forked from it. Operators who have already
+set the var explicitly (shell export, Foreman's `.env` load,
+Dockerfile `ENV`) skip the re-exec — the `nil?` guard preserves
+deliberate `=NO` settings if anyone has a reason for those. The
+operator-facing shell call (`bundle exec hyperion …`) sees a single
+child and a single exit status; the re-exec is invisible.
+
+`lib/hyperion.rb`'s 2.16.1 `ENV ||=` line is removed: it was
+misleading (couldn't work for the current process anyway).
+Programmatic users embedding Hyperion via `require 'hyperion'`
+without `bin/hyperion` on macOS must set the env var themselves in
+the shell or wrapper before launching Ruby — same as before 2.16.1.
+
+**Verification.**
+
+- `bin/check` green.
+- Fresh `bundle exec hyperion -C config/hyperion.rb config.ru` against
+  the same Rails 8.1 app that reproduced the 2.16.1 crash loop:
+  master + workers boot cleanly; no `NSCharacterSet`-init crash; no
+  worker respawn churn; sequential curls return 200 OK.
+
+## 2.16.1 — 2026-05-04
+
+### 2.16.1-A — macOS Obj-C fork-safety guard
+
+**Why.** Operators landing on 2.16.0's `preload false` mode on macOS
+were still hitting a second fork+macOS crash, distinct from the
+Network.framework deadlock that 2.16.0 addressed. The Obj-C runtime's
+post-fork sanity check trips when a worker touches a Foundation
+class that was mid-initialization in the master at fork time:
+
+```
+objc[…]: +[NSCharacterSet initialize] may have been in progress in
+another thread when fork() was called. We cannot safely call it or
+ignore it in the fork() child process. Crashing instead.
+```
+
+`NSCharacterSet` (and friends) load transitively through OpenSSL,
+the system resolver, and several other native gems. The result with
+many workers (`WEB_CONCURRENCY=0` on a multi-core box): every fresh
+worker crashes on first Foundation touch, master respawns, ad
+infinitum until graceful_timeout fires.
+
+The escape hatch on macOS is the documented env var
+`OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES`, but it MUST be in the
+process environment before any Foundation class loads — setting it
+from `config/hyperion.rb` (parsed after gems load) is too late.
+
+**What 2.16.1-A ships.** `bin/hyperion` and `lib/hyperion.rb` set
+`ENV['OBJC_DISABLE_INITIALIZE_FORK_SAFETY'] ||= 'YES'` on `darwin`
+unconditionally — before any `require` brings in Foundation-touching
+code. `||=` honours operators who've set the var explicitly. No-op
+on Linux/BSD; affects only macOS.
+
+This is a defense-in-depth change, complementary to `preload false`:
+`preload false` keeps Network.framework's resolver state out of the
+master; this guard keeps Obj-C runtime fork-checks from crashing
+the workers when something else (OpenSSL etc.) still touches
+Foundation. Together they make the macOS dev experience match Linux.
+
+**Verification.**
+
+- `bin/check` green.
+- Hand-reproduced the `NSCharacterSet` worker-crash loop on macOS;
+  no longer reproduces in 2.16.1.
+
 ## 2.16.0 — 2026-05-04
 
 ### 2.16-A — `preload false`: macOS fork+resolver escape hatch

data/bin/hyperion

@@ -1,6 +1,32 @@
 #!/usr/bin/env ruby
 # frozen_string_literal: true
 
+# 2.16.2 — macOS fork-safety. The Obj-C runtime caches the value of
+# `OBJC_DISABLE_INITIALIZE_FORK_SAFETY` at dyld init time, BEFORE any
+# Ruby code runs. Setting `ENV[...]` from Ruby is observable to
+# `Process.fork`'s child via inheritance, but the runtime's own
+# fork-safety check has already locked in its decision based on the
+# env it saw at process launch. So a Ruby-side `ENV[...] = 'YES'`
+# does not stop the post-fork crash:
+#   "+[NSCharacterSet initialize] may have been in progress in another
+#    thread when fork() was called. We cannot safely call it or ignore
+#    it in the fork() child process. Crashing instead."
+#
+# The reliable way to get the var into dyld's view is to re-exec the
+# Ruby process with it set. Once the new process starts, dyld picks
+# up the env var and the runtime's fork-safety check honours it.
+# `exec` replaces the current image so the wrapper shell call (e.g.
+# `bundle exec hyperion …`) sees a single child process and a single
+# exit status — no double accounting from the operator's side.
+#
+# Operators who've already set the var explicitly (in their shell, in
+# Foreman's .env load, in a Dockerfile ENV) skip this re-exec — we
+# only re-exec when the var is unset.
+if RUBY_PLATFORM.include?('darwin') && ENV['OBJC_DISABLE_INITIALIZE_FORK_SAFETY'].nil?
+  ENV['OBJC_DISABLE_INITIALIZE_FORK_SAFETY'] = 'YES'
+  exec(RbConfig.ruby, __FILE__, *ARGV)
+end
+
 $LOAD_PATH.unshift(File.expand_path('../lib', __dir__))
 require 'hyperion/cli'
 Hyperion::CLI.run(ARGV)

data/lib/hyperion/version.rb

@@ -1,5 +1,5 @@
 # frozen_string_literal: true
 
 module Hyperion
-  VERSION = '2.16.0'
+  VERSION = '2.16.2'
 end

data/lib/hyperion.rb

@@ -1,5 +1,13 @@
 # frozen_string_literal: true
 
+# Note: macOS Obj-C fork-safety is handled in `bin/hyperion` (re-exec
+# with `OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES`). It cannot be handled
+# from this file: setting `ENV[...]` from Ruby runs after dyld has
+# already cached its decision, so by the time `require 'hyperion'`
+# fires, the runtime's fork-safety check has locked in. Operators
+# embedding Hyperion programmatically (no `bin/hyperion`) on macOS
+# must set the env var in their shell or wrapper before exec.
+
 require_relative 'hyperion/version'
 require_relative 'hyperion/logger'
 require_relative 'hyperion/metrics'

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: hyperion-rb
 version: !ruby/object:Gem::Version
-  version: 2.16.0
+  version: 2.16.2
 platform: ruby
 authors:
 - Andrey Lobanov