[Bug]: Adding -Djruby.reify.classe=true to JAVA_ARGS results in service crash starting with 8.12.0

[Sharpie]

Is this a critical security issue?

• This is not a security issue.

Describe the Bug

Starting with the 8.12.0 release of OpenVox Server, adding the -Djruby.reify.classe=true property to JAVA_ARGS results in the puppetserver service crashing early during start-up. This crash is present in the 8.13.0 and 8.12.0 releases, and not in the 8.11.0 release.

This flag is commonly used when troubleshooting memory issues as it disables a JRuby optimization that obscures class names. With the flag enabled, heap dumps show actual Ruby class names instead of instances of anonymous Java classes.

Expected Behavior

puppetserver.service starts normally when -Djruby.reify.classe=true is present in JAVA_ARGS.

Steps to Reproduce

1. Start a Debian 13 container:

podman run --rm -it debian:13 /bin/bash

2. Activate the OpenVox package repositories:

apt update && apt install -y curl
curl -LO https://apt.voxpupuli.org/openvox8-release-debian13.deb
dpkg -i openvox8-release-debian13.deb
apt update

3. Install OpenVox server version 8.13.0:

apt install -y openvox-server=8.13.0-1+debian13

4. Start puppetserver foreground, observe normal startup sequence, then shut down with Ctrl-C:

# /opt/puppetlabs/server/bin/puppetserver foreground
2026-05-21T14:35:18.121Z INFO  [main] [p.t.s.w.jetty10-core] Removing buggy security provider SunPKCS11 version 21
2026-05-21T14:35:18.372Z INFO  [async-mixed-1] [p.t.s.s.scheduler-service] Initializing Scheduler Service
...
2026-05-21T14:35:23.605Z INFO  [async-mixed-1] [p.s.m.master-service] Puppet Server has successfully started and is now ready to handle requests
...

^C
...
2026-05-21T14:36:29.620Z INFO  [Thread-1] [p.t.internal] Finished shutdown sequence
 ...killed.

5. Add -Djruby.reify.classe=true to JAVA_ARGS in /etc/default/puppetserver:

sed -i 's/^JAVA_ARGS="/JAVA_ARGS="-Djruby.reify.classes=true /' /etc/default/puppetserver

6. Start puppetserver foreground again, observe crash:

# /opt/puppetlabs/server/bin/puppetserver foreground
2026-05-21T14:40:55.214Z INFO  [main] [p.t.s.w.jetty10-core] Removing buggy security provider SunPKCS11 version 21
2026-05-21T14:40:55.451Z INFO  [async-mixed-1] [p.t.s.s.scheduler-service] Initializing Scheduler Service
...
2026-05-21T14:41:29.114Z INFO  [main] [p.t.internal] Finished shutdown sequence
Execution error (LoadError) at org.jruby.RubyKernel/require (org/jruby/RubyKernel.java:1187).
(LoadError) no such file to load -- concurrent

Full report at:
/tmp/clojure-12956733994364462012.edn

Crash disappears if openvox-server package is downgraded to 8.11.0:

# Dpkg::Options retain modified /etc/default/puppetserver
apt install -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" -y --allow-downgrades openvox-server=8.11.0-2+debian13

Environment

Version: 8.12.0, 8.13.0
Platform: Debian 13, Java 21

Additional Context

puppetserver-reify-crash.log
clojure-3361516529348986590.edn.log

Relevant log output

[nmburgan]

We updated concurrent-ruby in 8.12.0

227f648#diff-bcdfa0d7393eff8e3e9414c5bc7900a98c63ab3e27958ea1e7c1f66009a08e98

Why that causes problems simply doing require 'concurrent' I have no idea.

[Sharpie]

Hmm, downgrading to the 1.2.3 version that was in use before that change does not clear the error:

/opt/puppetlabs/server/bin/puppetserver gem uninstall --install-dir /opt/puppetlabs/server/data/puppetserver/vendored-jruby-gems/ concurrent-ruby

/opt/puppetlabs/server/bin/puppetserver gem install --install-dir /opt/puppetlabs/server/data/puppetserver/vendored-jruby-gems/ concurrent-ruby --version 1.2.3

So, either there's a concurrent-ruby baked into the JAR file that puppetserver gem isn't operating on, or there's something else going on.