Repository navigation
Settings: a failed read no longer warns, and the supervisor reconnects to log - #1995
Merged
fog-workflows[bot] merged 2 commits intoOct 28, 2026
Merged
Conversation
…s to log PDODB::get() answers false when a read fails. getSetting() and _loadAllSettings() cast that to an array and iterated it; (array) false is [false], so each failed read wrote "Trying to access array offset on false" at FOGBase.php:3747 and :3752. A failed bulk load also emptied the cache in refreshSettingsCache() and could persist an empty cache file. Both loaders now treat a non-array result as a failure: a stale entry keeps its value and is retried next call, and a failed bulk load replaces nothing. The daemon supervisor is where the failures came from. On RC18 it shares a socket with its child, so its reads fail while the child starts or stops. Since #1930 it closes that socket before each fork, but its next log line can still read a setting -- the log gate, once the cache entry is past its TTL. The #1930 commit said the supervisor makes no queries after the fork; that was wrong. Service_Log_message() now reopens the link first, the same call the child makes. Service_persist() still closes it before every fork, so no child inherits it. tests/settings-read-failure.test.php runs the real FOGBase on a DB stub that fails every read; on the unfixed tree it reports the reporter's exact warnings. A shadow-tree run of the real Service_Log_message() after disconnect(): unfixed, 3 warnings and the link left closed; fixed, none and the link open. Fixes #1994 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
global-class-prefix requires it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #1994.
Problem
Every FOG service restart writes
Trying to access array offset on falseatFOGBase.php:3747and:3752toservicemaster.log.Cause
PDODB::get()answersfalsewhen a read fails.getSetting()and_loadAllSettings()iterated(array) false, which is[false].Change
Service_Log_message()reopens the link before it formats the time.Service_persist()still closes it before every fork, so no child inherits it.Verification
tests/settings-read-failure.test.php(new): realFOGBase, DB stub that fails every read. Red on the base with the reported warnings, green here.tests/service-fork-fresh-db-link.test.php([FOG 1.6.0-RC-15] Daemon startup failures caused by inherited PDO connections after pcntl_fork() #1930) still passes.Service_Log_message()afterdisconnect(): base gives 3 warnings and a closed link; this branch gives none and an open link.Reach
RC18 users get this in the next RC. An
rc-1.6.0port follows.🤖 Generated with Claude Code