Restart Sophos Firewall services safely

The easiest way to restart an individual Sophos Firewall service is under System services > Services. If the service is not listed there, the Advanced Shell can be used. First, however, identify the affected service and determine which connections a restart could interrupt.

⚠️ Important: Restarting a service changes the system state and can interrupt VPN, routing, DNS, DHCP, web access or administrator access. Save the status and logs beforehand, and have an alternative access method available for remote sites.

Restart a service through WebAdmin

1. Open System services > Services.
2. Check the affected service and its current status.
3. Under Manage, click Restart.
4. Then test the status and the affected function.

WebAdmin lists services including Anti-spam, Antivirus, Authentication, DNS server, IPS, Web proxy, WAF, DHCP server, Hotspot and Packet capture and Live connections. If a service is not configured, its button remains disabled. Anti-spam requires an inbound or outbound spam policy. Stopping Packet capture and Live connections ends running captures and makes the Live Connections view unavailable.

Under Control Center > System, the services status indicates whether a service is stopped or failed to start. This is a useful starting point, but it does not replace a functional test. If only the WebAdmin interface has stopped responding, follow Restart the Sophos Firewall WebAdmin GUI.

Antivirus service stopped after failed pattern updates

If the Antivirus service remains stopped after failed SAVI and AVIRA pattern updates, do not click Restart repeatedly. First save the firmware version and build, the time of the failure, and the related avd.log and up2date_av.log files. Under Backup & firmware > Pattern updates, also record the last successful update and the current state: Ready to install, Downloading, Success, or Failed. The general process for checking these states is described in Configure and check Sophos Firewall pattern updates.

Sophos tracks this issue as NC-180066; it is fixed in SFOS 22.0 MR2 Build 546. If the symptoms match on an older SFOS 22 build, check the supported path with the firmware update preparation guide and upgrade to MR2 Build 546 or a later approved version first. A single restart under System services > Services is generally available, but Sophos does not document it as a workaround or fix for NC-180066, and it does not replace the firmware update.

Only after the firmware update, click Update pattern now under Backup & firmware > Pattern updates. The affected Antivirus pattern update must reach Success, and the Antivirus service must remain active. The displayed service status alone is not enough: the pattern update must also complete successfully. If the issue occurs again on MR2 Build 546 or later, provide the saved logs and timestamps to Sophos Support rather than continuing to assume NC-180066.

Restart a service through the Advanced Shell

The Advanced Shell is useful when the service is not available in WebAdmin or Sophos Support provides a specific command. For SSH access and host key verification, follow Connect to Sophos Firewall through SSH. SSH should be allowed only from trusted administration networks; the relevant settings are covered in Device Access and Local Service ACL. Inactive SSH sessions are closed after 15 minutes.

After signing in, open:

5. Device Management > 3. Advanced Shell

The Advanced Shell provides extensive system access. Run read-only checks first and trigger a restart only afterwards.

1. Check the service name and status

To display known services and their current state, run:

service -S

The output can be filtered for the suspected service. For IPsec, for example, run:

service -S | grep -i strongswan

RUNNING means that the service is running. STOPPED, UNREGISTERED or UNTOUCHED do not automatically indicate a fault: depending on the firmware and configuration, a service may intentionally be inactive or unregistered. First check whether the associated function, policy or licence is used at all.

If the technical service name is unclear, see Sophos Firewall troubleshooting: services and logs. It maps functional areas to their log files.

2. Check logs before making a change

A restart can obscure important clues about the cause. For IPsec, read strongswan.log first and save the relevant messages:

less /log/strongswan.log

Press q to exit less. For larger investigations, export the logs beforehand as described in Save Sophos Firewall logs for support and analysis. In HA clusters, each node stores only the logs for traffic it processes; both nodes may need to be checked separately.

3. Restart the service on a standalone firewall

The following example assumes a standalone firewall. Before running it, service -S | grep -i strongswan must confirm the service. The restart can interrupt site-to-site and remote access IPsec connections. Check tunnels, remote peers and the maintenance window first.

Sophos documents this pattern:

service <service>:restart -ds nosync

A complete example for the IPsec service is:

service strongswan:restart -ds nosync

For further analysis, see Sophos Firewall IPsec troubleshooting.

⚠️ HA cluster: Do not apply the standalone command without verification. Depending on the service and situation, Sophos instructions use sync or nosync; the public documentation does not provide a sufficient general rule. The service, node, SFOS build and synchronisation mode must come from current service-specific Sophos instructions or a support case.

Separate stop and start commands should be used only when Sophos Support instructs you to do so for the specific service. The service remains fully stopped between the two commands.

4. Validate the result

After the restart, check the status, log and actual function:

service -S | grep -i strongswan
tail -f /log/strongswan.log
grep -i 'error' /log/strongswan.log

tail -f displays new messages continuously and is stopped with Ctrl+C. Then check the IPsec tunnels and test a host at the remote site. A service status of RUNNING alone does not prove that the connection works again.

If the restart fails, also check csc.log. For HA problems, ha.log, msync.log and applog.log may also be relevant, depending on the symptoms.

Common services and appropriate functional tests

Confirm the exact service name on the affected firewall with service -S. The most important mappings are:

• strongswan: Site-to-site and remote access IPsec. Afterwards, check tunnel status, strongswan.log and reachability of the remote site.
• dnsd: DNS service. Afterwards, test internal and external name resolution, dnsd.log and any configured DNS request routes.
• dhcpd: DHCP server. During a restart, new or renewing clients may not receive a response. Afterwards, test lease assignment and dhcpd.log.
• awed: Communication between the firewall and AP/APX devices. Afterwards, check the access point connection status and awed.log.
• zebra: Installs dynamic and static routes in the kernel. A restart is therefore invasive and should be performed only with specific Sophos instructions; afterwards, test the routing table, gateways and actual paths.
• smtpd: SMTP proxy in MTA mode. The transparent legacy proxy uses a different service; check the operating mode and smtpd_* logs before making a change. Afterwards, test controlled mail sending and receiving.

For WAF, Web proxy, IPS, Authentication and services available in WebAdmin, restarting under System services > Services is usually clearer than using a shell command.

When a service restart is not appropriate

Restarting an individual service is appropriate when a specific module is affected and the rest of the firewall is stable. Do not restart services blindly when:

• the cause or affected service is still unclear;
• several core services fail at the same time;
• that service provides the only remaining remote access;
• the problem is reproducible and the logs have not yet been saved;
• the same service has already been restarted several times;
• the HA role, node or required synchronisation mode is unclear.

If several services are affected, first check system load, storage, database state, HA and the latest configuration or firmware changes. Repeated restarts often only conceal the root cause.

A full reboot is more invasive and should be considered only when the firewall remains unstable overall, a firmware or hotfix process requires it, or Sophos Support instructs it. Before rebooting a remote firewall, confirm the backup, maintenance window and recovery path, such as a local contact, out-of-band access or a working HA peer. See Plan Sophos Firewall backup and restore correctly.

Document the change briefly

For recurring problems or a support case, a short note is sufficient. It shows later whether the restart provided a lasting fix or merely concealed a symptom:

Date/time and time zone:
Firewall / HA node:
Service and command:
Reason:
Users/sites affected:
Logs checked before restart:
Result after restart:
Next action:

Before making the change, record the time, affected function and relevant log messages. Afterwards, record the service status, functional test and next action. Remove temporary SSH or Device Access rules and disable debug modes after the investigation.