Lab Objective

Compare a desired configuration value with the environment of the running process, its service log, and its status endpoint. The lab demonstrates why a changed file is not proof that a live service reloaded the policy.

Lab Environment

  • Environment: local Ollama service and a launch/start helper
  • Setting: model keep-alive duration
  • Safety boundary: read-only inspection first; use a test service or maintenance window for restart work
  • Evidence: process environment, service log, and API response

Scenario

The launch configuration requested a two-hour keep-alive, but the already-running service still reported twenty-four hours. A control-plane environment update cannot rewrite the environment inherited by an existing process.

Step 1 - Record the Declared Value

Read the intended value from the launch configuration and record the process identity you expect to serve requests. Do not change anything yet.

Step 2 - Inspect the Running Process

On a controlled local system, inspect the service process environment. For Ollama, the source investigation used a command equivalent to:

ps eww "$(pgrep -x ollama)" | tr ' ' '\n' | grep OLLAMA_KEEP_ALIVE

The result is evidence about the process that is alive, not about a file that may be used only at the next start.

Step 3 - Query the Service

Ask the local status endpoint what it believes is active. For the tested local service, the status query was:

curl 127.0.0.1:11434/api/ps

Compare the reported TTL with the process environment and the declared value.

Step 4 - Test Startup Ordering

Review the helper’s order: guard, restart, then preload. A preload before a quiet-window guard can recreate the condition that blocks a safe restart. The helper must also export the intended environment for the process it starts.

Step 5 - Prove Consistency

Accept the change only when all three observations agree:

declared_value=2h
process_value=2h
service_value=2h
result=consistent

If the values disagree, report the control as not yet active.

Security Takeaways

  1. Runtime state outranks static intent when verifying an active control.
  2. A clean exit code does not prove a postcondition.
  3. Restart, guard, and preload ordering can create hidden failure loops.
  4. Process identity must be tied to the configuration being checked.
  5. Availability and resource controls also need live verification.

Where This Applies Beyond the Lab

Use the same method for firewall rules, authentication policy, scheduled jobs, endpoint agents, proxy settings, and container environments. Query the component that serves traffic.