Sophos Firewall Log Viewer Shows No New Logs

If the Log Viewer on SFOS 22 shows no new events, do not restart a service on suspicion alone. First determine whether only one expected entry is missing or whether the local log display has stopped entirely. For normal operation, filters, and field interpretation, start with Use Sophos Firewall Log Viewer correctly. The safe quick path for a stalled viewer is:

In Log Viewer, check Pause, the module, time range, and active filters, then run Reset and Refresh.
In the affected firewall rule, check Log firewall traffic and under System services > Log settings, verify the Firewall log type for Local reporting.
Generate a short connection from a known test client and note the time.
Under Diagnostics > Packet capture > Configure, set a narrow BPF filter, turn on capture, and check whether the traffic reaches the firewall and which Rule ID is processed.
Turn capture off after the test. Only if other expected events are also missing, record the SFOS version, full build, and the time of the last visible log entry.
On SFOS 22, do not use a Garner or database workaround from an older version. Check the current maintenance release and give the diagnostic data to Sophos Support if all local logs have stopped.
The retained Garner workaround below belongs exclusively to SFOS 21.5.1 MR1 Build 261 and the exact documented error pattern.

This keeps troubleshooting traceable: an incorrect filter or a rule that does not log is not confused with a logging database error.

Why a Single Log Entry May Be Missing

Log Viewer normally updates automatically. However, it only shows events that the selected module stores locally and that are not hidden by the current view.

Common causes that do not indicate a technical Viewer failure include:

Pause is active: New events only become visible after resuming or refreshing manually.
Module, time range, or filters do not match: Reset removes all filters; then select the technically relevant module again.
Rule logging is disabled: Firewall sessions only appear if Log firewall traffic is enabled in the rule that actually matches.
Local reporting is disabled: Under System services > Log settings, the required log type must be selected in the Local reporting column.
The connection is still open: Firewall sessions are normally logged with the Destroy event when the connection ends. An entry can therefore appear later than the initial connection attempt.
The session ends without a Destroy event: If the internet connection is lost, for example, the session may close without any log entry. The entry is then not merely delayed; it is never created.
The traffic does not reach the firewall: A missing log entry does not prove that the firewall dropped the packet. The client, an upstream router, DNS, or another path may already prevent the connection.
Firewall Log suppression consolidates repetitions: Suppressed subsequent firewall events may be combined under Log occurrence instead of appearing as many individual rows.

If Log Viewer continues to show new system or firewall events from other tests, the display is generally working. The cause is then more likely rule logging, module selection, filters, session termination, or the actual packet path. For this distinction, test the firewall rule with Log Viewer, Policy Tester, and Packet Capture.

Generate a Controlled Test Flow

A reproducible test is more reliable than waiting for random user traffic. In the following example, the test client uses the adaptable IP address 10.20.30.25. On the client, not in the firewall shell, establish a short HTTPS connection:

curl -I https://example.com/

example.com is a reserved example domain. A known and permitted HTTPS service in the environment can also be used for the test. What matters is that the process closes the connection and that the time, client IP, and destination are known.

Then check in this order:

Under Rules and policies > Firewall rules, verify that the expected rule has Log firewall traffic enabled.
In Log Viewer, run Reset, select the Firewall module and a suitable time range, and filter for 10.20.30.25.
Wait a few seconds and refresh once manually because the firewall event may only appear after the session ends.
If the entry is missing, go to Diagnostics > Packet capture, click Configure, enter the narrow filter host 10.20.30.25 under Enter BPF string, and save it. Replace the IP address with the actual test client address.
Turn on Packet capture, repeat the test once, and then turn capture off again. This limits the capture to the known client and a short time window.

The observation determines the next step:

Packet Capture sees no test traffic: Look for the cause before the firewall or on the client.
Packet Capture shows a different Rule ID: Check the rule that actually matches and its logging.
Other new Log Viewer events appear: The Viewer has not stopped completely; continue investigating filters, log type, and the specific rule.
Packet Capture confirms the flow, rule logging and Local reporting are correct, but all new events remain absent: Check the build and local log processing.

Packet Capture shows the packet flow but does not repair the log display. If the buffer is full and Wrap capture buffer once full is not selected, SFOS stops capturing automatically; Clear releases the buffer for another test. Packet Capture in Sophos Firewall WebAdmin explains its use and status values.

Classify the Failure on SFOS 22

The Sophos Known Issues List limits NC-175936 to SFOS 21.5.1 MR1 Build 261 and explicitly states that the issue is resolved in version 22. The associated Garner restart is therefore not a repair path for SFOS 22.

The SFOS 22 release notes list further Logging Framework changes. SFOS 22.0 GA Build 411 fixed NC-169237, where database corruption caused Log Viewer to lose events. SFOS 22.0 MR1 Build 490 fixed NC-152553, a failed recovery mechanism for active.db. The latest version listed there, SFOS 22.0 MR2 Build 546, improves Log Viewer performance under NC-181520.

These entries confirm resolved defects; they do not identify the cause of a current outage. On SFOS 22, record the exact version and build, check a supported upgrade path to the current maintenance release, and do not modify database files or restart a logging service from the shell if events remain absent.

Check `NC-175936` on SFOS 21.5.1 MR1 Build 261

Sophos documents issue NC-175936 for SFOS 21.5.1 MR1 Build 261: the file /tmp/eventlogs/active.db may be missing, causing Log Viewer to stop displaying new data. According to Sophos, the firewall continues to process traffic; the security functions remain active. This statement describes the known issue and is not a general health confirmation for a firewall without logs.

Sophos also states explicitly that this issue is resolved in version 22. Therefore, do not use the following legacy workaround on SFOS 22 or on another build based only on a similar symptom.

Read-Only Pre-Checks in the Advanced Shell

First record the full build, time, last visible event, and, for HA, the affected node. If WebAdmin still works, save garner.log and, if possible, a Consolidated Troubleshooting Report before making the change.

Then connect through the documented SSH access to Sophos Firewall and open the Advanced Shell. The following commands only read storage status, the file, and the log:

df -kh /tmp
ls -l /tmp/eventlogs/active.db
tail -n 200 /log/garner.log

df -kh /tmp shows whether free space remains on the file system. ls -l confirms whether active.db exists; if it is missing, the shell may display a message such as No such file or directory, depending on the build. Check garner.log for errors at the documented test time. Map Sophos Firewall service logs correctly explains additional service names and log files.

If /tmp is full, the file exists, the build differs, or the symptom is not unambiguous, do not perform the following restart. Do not delete, copy, or manually create files under /tmp/eventlogs.

Restart Garner Once in a Controlled Manner

⚠️ State-changing command: This workaround applies only to the documented error pattern on SFOS 21.5.1 MR1 Build 261. Save logs and system state first. In an HA cluster, do not run the command on both nodes without a verified procedure. Do not restart Garner repeatedly, and never repair or delete active.db manually.

For NC-175936, Sophos specifies exactly this command in the Advanced Shell:

service garner:restart -ds nosync

The command was taken from the current Sophos Known Issues List for this article but was not lab-tested on an appliance. A service restart cannot be rolled back; if the file remains absent or events still do not appear, stop here and give the recorded pre-change state to Sophos Support. After the single restart, check the file and the latest Garner messages again using read-only commands:

ls -l /tmp/eventlogs/active.db
tail -n 50 /log/garner.log

Then run Reset and Refresh in Log Viewer and repeat the same short test flow. The action is successful only when a new event with a matching timestamp appears. The presence of active.db alone does not prove that the complete logging path works again.

If SFOS 22 Still Shows No New Events

If Packet Capture shows the controlled test flow on SFOS 22, rule logging and Local reporting are correct, and new events are still absent across modules, first plan a supported SFOS firmware upgrade path to the current maintenance release. If the problem remains on the current build, do not attempt database or service interventions.

For a support case, collect at least:

Appliance model, SFOS version, and full build;
for HA, the affected node and its role;
timestamp of the last visible Log Viewer entry and time of the test flow;
module, filters, Rule ID, Source, Destination, and Service of the test;
status of Log firewall traffic and Local reporting;
Packet Capture result;
for the exact matching 21.5.1 MR1 error pattern, output of df -kh /tmp and ls -l /tmp/eventlogs/active.db;
garner.log, fwlog.log, and iview.log when needed, plus a CTR if possible before further changes;
whether the Garner restart was performed once and what changed afterwards.

This allows Sophos to distinguish between display, database, storage, service, and version-specific errors without repeated repair attempts obscuring the original cause.