gateway.log_path: config validates but no file is ever created

[matejaarqitech]

Question

Is gateway.log_path implemented in 0.5.8, and if so, what does it log and what triggers the first write? No file ever appears at the configured path in our deployment.

What we configured

gateway {
  # ...
  log_path = "/var/log/clawpatrol/gateway.log"
}

The directory is created by systemd (LogsDirectory=), owned by the service user, mode 0700. It is one of only two writable paths for the unit, which runs with ProtectSystem=strict.

What we observed

• clawpatrol validate accepts the config, and the service starts cleanly with no warning or error mentioning the log path.
• After the deploy plus roughly fifteen minutes of brokered traffic, the directory is still empty. That traffic included denied requests, which do appear in the journal, and an HTTP 401 on /api/config.
• Normal startup and deny lines reach the journal as usual, so logging itself works — just not to the file.

We could not isolate this with a second instance: the MITM listener is fixed at 127.0.0.1:8443 and host_loopback_port is not a gateway block attribute, so a sandbox gateway cannot start alongside the real one. Happy to inspect /proc/<pid>/fd or run any other diagnostic if that would help distinguish "never opened" from "opened but buffered".

Why we want it

/api/config requests appear nowhere in the journal, so a client that is silently failing to fetch its configuration is invisible from the gateway side. We hit exactly that: a macOS client whose network extension could not fetch config, where all the evidence lived on the client and the gateway showed nothing at all. A file-based log covering the config channel would have made it visible from the operator side.

Related and possibly the same root cause: ALLOW decisions are not journaled either — they are recorded in the state database and surface in the dashboard audit view — so the journal is deliberately not a complete audit surface. If log_path is intended to be that complete surface, knowing so would be useful; if it is intended for something narrower, documenting its scope would help.

One small observation while looking for it: body_storage is nested inside a limits block while log_path sits directly on gateway, so if these were meant to be siblings, one of them may be attached in the wrong place.

[matejaarqitech]

Additional evidence: the gateway process holds no file descriptor for the configured path.

Inspecting /proc/<mainpid>/fd while the service is running and serving traffic returns nothing matching the log path or /var/log at all. Combined with the directory staying empty, that rules out the "opened but buffered, or rotated elsewhere" explanation — the file is never opened in the first place.

So in 0.5.8 gateway.log_path appears to be parsed and accepted but not wired to anything. If that is expected for this release, it would be worth either rejecting the key at validation time or noting it as reserved, since a silently ignored logging option reads as an audit control that is in place when it is not.