One Hat Cyber Team

Your IP: 216.73.216.72
Server IP: 41.128.143.86
Server: Linux host.raqmix.cloud 6.8.0-1025-azure #30~22.04.1-Ubuntu SMP Wed Mar 12 15:28:20 UTC 2025 x86_64
Server Software: Apache
PHP Version: 8.3.23
Buat File | Buat Folder

Dir : ~/usr/share/doc/passenger/passenger/DesignAspects/

View File Name : NoGemActivationDuringRubyLoaderInitialization.md

# No gem activation during Ruby loader initialization

## Context

Passenger loads a Ruby app using loader scripts (rack-loader.rb and rack-preloader.rb). These scripts perform these steps:

1. Initialization, e.g., to setup communication with the Passenger Core.
2. Activate Bundler.
3. Load the application (config.ru).

If step 1 activates any gems, then that may conflict with Bundler activation because Gemfile could specify a different gem version.

## Decision

All code callable by the Ruby loaders' initialization steps, must not activate any gems.

## Consequences

Any needed functionality that's typically provided by gems, must be reimplemented within the `PhusionPassenger` module.

For example, the initialization step needs to parse JSON. Instead of activating the JSON gem, we reimplement a JSON parser in `PhusionPassenger::Utils::JSON`.

### Caveat: standard library gems

More and more parts of the Ruby standard library are becoming [gemified](https://stdgems.org/). This increases the chances of the initialization step activating a standard library gem. In principle, our strategy remains the same: we reimplement those libraries. For example, we reimplemented StringScanner (needed by our JSON implementation) in `PhusionPassenger::Utils::StringScanner`, but we limited its scope to just the functionality needed by the JSON implementation.

If the standard library in question is a native extension (e.g., `etc`), then the strategy is to reimplement it in C++ as part of the [Passenger Agent binary](../../src/agent/README.md), as a separately callable tool. The Ruby code then spawns the written-in-C++ tool and parses its output.