Sophos Firewall Log Viewer Shows No New Logs

If the Log Viewer shows no new events, do not immediately restart a service. 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:

1. In Log Viewer, check Pause, the module, time range, and active filters, then run Reset and Refresh.
2. In the affected firewall rule, check Log firewall traffic and under System services > Log settings, verify the Firewall log type for Local reporting.
3. Generate a short connection from a known test client and note the time.
4. Use Packet capture to check whether the traffic reaches the firewall and which Rule ID is processed.
5. Only if other expected events are also missing, record the SFOS version, full build, and the time of the last visible log entry.
6. Use the Garner workaround only on SFOS 21.5 MR1 Build 261 and only for the error pattern described below.

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 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:

1. Under Rules and policies > Firewall rules, verify that the expected rule has Log firewall traffic enabled.
2. In Log Viewer, run Reset, select the Firewall module and a suitable time range, and filter for 10.20.30.25.
3. Wait a few seconds and refresh once manually because the firewall event may only appear after the session ends.
4. If the entry is missing, use a narrow filter such as host 10.20.30.25 under Diagnostics > Packet capture and repeat the same test.

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. Packet Capture in Sophos Firewall WebAdmin explains its use and status values.

Check NC-175936 on SFOS 21.5 MR1 Build 261

Sophos documents issue NC-175936 for SFOS 21.5 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.

The current Sophos Known Issues List does not provide an unambiguous fixed-version field for 21.5 MR2. Therefore, do not use the following workaround on other builds 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 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. 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.

Other Builds and Recurring Failures

Sophos has fixed other but non-identical issues involving the Log Viewer database. SFOS 22.0 MR1 Build 490 includes NC-152553, a fix for a failed recovery mechanism of active.db; NC-169237, concerning lost Log Viewer events caused by database corruption, is listed for SFOS 21.5 MR2 Build 323 and SFOS 22.0 GA Build 411. These issue IDs neither prove a fix for NC-175936 nor automatically identify the cause of a current failure.

On an older build, first plan a supported SFOS firmware upgrade path. On a current build or after an unsuccessful Garner restart, do not attempt further 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;
• 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.