Is this a critical security issue?
Describe the Bug
TrapperKeeper applications, that is OpenVox Server and OpenVoxDB, go through a startup phase that is mostly driven from the run function in core.clj:
https://github.com/OpenVoxProject/trapperkeeper/blob/5.0.5/src/puppetlabs/trapperkeeper/core.clj#L151-L169
The first function call, boot-with-cli-data, blocks until the application has finished its start cycle. This can take several seconds, during which run is blocked. Once the start cycle is finished, internal/register-sighup-handler is executed to set up SIGHUP handling.
This order of operations means that while start is executing, the JVM default SIGHUP handler is in place and the process will exit if it receives a reload signal:
The JVM catches signals to implement shutdown hooks for unexpected termination. The JVM uses SIGHUP, SIGINT, and SIGTERM to initiate the running of shutdown hooks.
https://docs.oracle.com/en/java/javase/21/docs/specs/man/java.html#extra-options-for-java
Expected Behavior
Sending a reload signal to a TrapperKeeper process undergoing startup should not cause it to suddenly blink out of existence. The signal should either be ignored, or buffered and used to trigger a reload after start finishes.
Steps to Reproduce
-
Obtain a RedHat 10 VM
-
Install OpenVox Server:
dnf install -y https://yum.voxpupuli.org/openvox9-release-el-10.noarch.rpm
dnf install -y openvox-server-9.0.0~beta5
- Use the following test script to start the
puppetserver service and send it an early SIGHUP:
#!/bin/bash
printf '%s\n' 'Stopping service...'
systemctl stop puppetserver
touch /tmp/test-start-time
printf '%s\n' 'Watching logs...'
journalctl -f _SYSTEMD_UNIT=puppetserver.service + SYSLOG_IDENTIFIER=puppetserver &
log_watch_pid=$?
systemctl start --no-block puppetserver.service
while [ /tmp/test-start-time -nt /var/run/puppetlabs/puppetserver/puppetserver.pid ]; do
sleep 1
done
pid=$(cat /var/run/puppetlabs/puppetserver/puppetserver.pid)
kill -HUP $pid
while kill -0 $pid &>/dev/null; do
sleep 1
done
kill -HUP $log_watch_pid
wait
Environment
Version 8.x, 9.x
Platform ANY
Additional Context
No response
Relevant log output
# ./test-hup.sh
Stopping service...
Watching logs...
Aug 21 20:53:03 rocky-10-tst puppetserver[16545]: 20:53:03,207 |-INFO in ch.qos.logback.core.rolling.SizeAndTimeBasedFileNamingAndTriggeringPolicy@4e36bceb - The date pattern is 'yyyy-MM-dd' from file name pattern '/var/log/puppetlabs/puppetserver/puppetserver-access-%d{yyyy-MM-dd}.%i.log.gz'.
Aug 21 20:53:03 rocky-10-tst puppetserver[16545]: 20:53:03,207 |-INFO in ch.qos.logback.core.rolling.SizeAndTimeBasedFileNamingAndTriggeringPolicy@4e36bceb - Roll-over at midnight.
Aug 21 20:53:03 rocky-10-tst puppetserver[16545]: 20:53:03,207 |-INFO in ch.qos.logback.core.rolling.SizeAndTimeBasedFileNamingAndTriggeringPolicy@4e36bceb - Setting initial period to 2026-08-20T22:02:34.126Z
Aug 21 20:53:03 rocky-10-tst puppetserver[16545]: 20:53:03,208 |-INFO in ch.qos.logback.core.model.processor.ImplicitModelHandler - Assuming default type [ch.qos.logback.access.common.PatternLayoutEncoder] for [encoder] property
Aug 21 20:53:03 rocky-10-tst puppetserver[16545]: 20:53:03,218 |-INFO in ch.qos.logback.core.rolling.RollingFileAppender[FILE] - Active log file name: /var/log/puppetlabs/puppetserver/puppetserver-access.log
Aug 21 20:53:03 rocky-10-tst puppetserver[16545]: 20:53:03,218 |-INFO in ch.qos.logback.core.rolling.RollingFileAppender[FILE] - Setting currentFileLength to 783375 for /var/log/puppetlabs/puppetserver/puppetserver-access.log
Aug 21 20:53:03 rocky-10-tst puppetserver[16545]: 20:53:03,218 |-INFO in ch.qos.logback.core.rolling.RollingFileAppender[FILE] - File property is set to [/var/log/puppetlabs/puppetserver/puppetserver-access.log]
Aug 21 20:53:03 rocky-10-tst puppetserver[16545]: 20:53:03,218 |-INFO in ch.qos.logback.core.model.processor.AppenderRefModelHandler - Attaching appender named [FILE] to default
Aug 21 20:53:03 rocky-10-tst puppetserver[16545]: 20:53:03,218 |-INFO in ch.qos.logback.core.model.processor.DefaultProcessor@77f07a48 - End of configuration.
Aug 21 20:53:03 rocky-10-tst puppetserver[16545]: 20:53:03,218 |-INFO in ch.qos.logback.access.common.joran.JoranConfigurator@344227ba - Registering current configuration as safe fallback point
Aug 21 20:53:08 rocky-10-tst puppetserver[16695]: Background process 16755 exited before start had completed
Hangup
Is this a critical security issue?
Describe the Bug
TrapperKeeper applications, that is OpenVox Server and OpenVoxDB, go through a startup phase that is mostly driven from the
runfunction incore.clj:https://github.com/OpenVoxProject/trapperkeeper/blob/5.0.5/src/puppetlabs/trapperkeeper/core.clj#L151-L169
The first function call,
boot-with-cli-data, blocks until the application has finished itsstartcycle. This can take several seconds, during whichrunis blocked. Once the start cycle is finished,internal/register-sighup-handleris executed to set up SIGHUP handling.This order of operations means that while
startis executing, the JVM default SIGHUP handler is in place and the process will exit if it receives a reload signal:Expected Behavior
Sending a reload signal to a TrapperKeeper process undergoing startup should not cause it to suddenly blink out of existence. The signal should either be ignored, or buffered and used to trigger a
reloadafterstartfinishes.Steps to Reproduce
Obtain a RedHat 10 VM
Install OpenVox Server:
puppetserverservice and send it an earlySIGHUP:Environment
Version 8.x, 9.x
Platform ANY
Additional Context
No response
Relevant log output