Conversation
Only an in-place TA modification set the flag that reloads system stanzas. A full TA add or removal shifts stanza ownership too: a known TA's deletion routes to pending[taDir] (not the "" all-TAs sentinel), so allTAs is false, the TA lands in the removed branch, and systemKey was never appended to changed. A stanza the TA had claimed then stays suppressed at the system layer until some unrelated later event forces a reconcile. Track ownership changes across the added, removed, and changed buckets and reload systemKey when any TA transition occurs, but only when systemKey is currently active so a reload is not scheduled for a key with no stanzas.
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
1 participant
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.
Problem
splunkinputsreceiverreloads system-level stanzas (etc/system, not owned by any TA) only on an in-place TA modification. A full TA add or removal shifts stanza ownership between a TA and the system layer just as much, but the reconcile loop missed both cases.A known TA's deletion routes to
pending[taDir]rather than the""all-TAs sentinel, soallTAsis false. The TA then lands in theremovedbranch, which never settaChanged, sosystemKeywas never appended tochangedandReadSystemInputswas not re-run.Concrete failure: system config defines
[monitor:///var/log/syslog]and TAsplunk_ta_xalso defines it. At Start the system copy is excluded and the TA collects it. Deletesplunk_ta_xat runtime: reconcile stops the TA receiver but does not reload system stanzas, so the stanza is collected by neither and silently stops being ingested until an unrelated later add/modify or system-conf event forces a reconcile.Fix
Track ownership changes across the
added,removed, andchangedbuckets (excludingsystemKeyitself) and reloadsystemKeyon any TA transition. Guard the reload onsystemKeybeing currently active: when all system stanzas were TA-owned,systemKeyis not inactiveand theaddedloop already reloads it, so scheduling achangedreload for a key with no stanzas is avoided.Found by a revmux review of #125.
Testing
Added reconcile subtests: TA removal and targeted TA change both reload active system stanzas; a targeted change with no active
systemKeydoes not conjure one. Verified the tests fail on the pre-fix code.Follow-ups
Two further findings from the same review are out of scope here and will be separate PRs: the
systemKeysentinel leaking into publicReceiverRequest.BaseDir, and new TA receivers starting before the losing system owner is stopped.