GURDN

Documentation / How it acts

Recovery

Rollback, reconciliation and refusing to force a mismatch.

Recovery is what happens when something did not go to plan. Its guiding rule is that GURDN would rather report an awkward truth than restore a state nobody asked it to restore.

Rollback

Every applied step recorded its undo before it ran. On failure, the completed steps are walked back in reverse order. A step whose current state no longer matches what it applied is refused rather than forced, because the mismatch means something else has changed it and overwriting that would destroy a change somebody made deliberately.

A rollback that itself fails is reported as a failed rollback. It is never described as restored.

Reconciliation after an interruption

If the machine restarted, the service stopped, or an operation was cut short, the next run has to work out what actually happened. Reconciliation observes and reports, with four possible outcomes:

  • The machine matches what was requested: the operation succeeded.
  • It matches the previous state: the operation failed and left nothing behind.
  • It matches neither: the outcome is undetermined, and says so.
  • It cannot be read: no verdict is produced, rather than a guessed one.
Reconciliation never replays a mutation. It is an observation, not a repair. A product that re-applies changes on startup is a product that can reconfigure your network because of something you authorised once, weeks ago, under different circumstances.

Startup does not invent state

After a restart the engine does not assume the state it last knew is still current. It observes first. Protective mode does not report itself as active until the controls behind it are observed to be active.

Supervision

The privileged service is supervised by Windows, which restarts it after ten, sixty and three hundred seconds. GURDN keeps the memory the Service Control Manager does not: three failures within an hour raise a recovery-required marker, report one event to the Windows Event Log, and stop GURDN applying further changes until the marker clears.

The point of stopping is that a component failing repeatedly is a component whose judgement should not be driving changes to a firewall. See troubleshooting for what you see when this happens.