Technical Tip: FortiGate WAD 'user-info' sub-process pinning a single CPU core to 100%, causing network instability

Description

This article describes how to troubleshoot an issue where a FortiGate WAD 'user-info' sub-process pins a single CPU core to 100%, causing network instability.

Scope

FortiGate physical appliances and VMs running FortiOS v7.4.x, confirmed on v7.4.12.

Solution

On FortiGate units with Device Identification / Device Detection enabled on several interfaces, the WAD (Web Application Daemon) user-info sub-process can become pinned at or near 100% utilization on a single CPU core.

Symptoms include the following.

• One CPU core, visible in 'diagnose sys top', is constantly at approximately 99 to 100%, with a wad process shown as the top consumer on that core.

• Intermittent network instability or performance issues correlate with the CPU pinning.

• Manually killing the WAD PID frees the core for only a few seconds before it pins again.

• A full device reboot provides only temporary relief, roughly an hour in the reported case, before the symptom returns.

No firewall configuration change is required to trigger this issue. It can appear from normal operation once the discovered-device table grows large enough.

To resolve the issue, follow the steps below.

1. Confirm the symptom.

Check per-core CPU usage and identify the offending process by running the following command:

diagnose sys top 1 99 1 | grep wad

Look for a WAD process pinned anywhere from 99% to 100% on a single core. Cross-check which WAD sub-process is responsible by running the following commands:

diagnose wad memory
diagnose sys process list

In confirmed cases, the responsible sub-process is wad user-info.

2. Check the size of the discovered-device table.

diagnose user device stats

A very high count value, tens of thousands or more, is consistent with this issue. The user-info sub-process has to continually scan and maintain this table, and an oversized table is what drives the CPU pinning.

3. Apply immediate relief.

config system settings
    set discovered-device-timeout 1
end

diagnose user device clear
diagnose test application wad 99

This shortens how long discovered devices are retained, shrinking the table the user-info sub-process has to scan, clears the existing bloated table, and restarts WAD so the change takes effect immediately.

CPU utilization on the affected core should return to normal within a few minutes. This workaround has been confirmed effective and stable over several days in a production environment.

4. Apply the permanent fix by contacting Fortinet Support and providing the outputs above.

Note: If Device Identification is not needed on every interface, consider disabling it on interfaces where the discovered-device data is not used. This limits how large the table can grow.

Note: This issue is unrelated to any specific configuration change. It may surface as the discovered-device table grows over time during normal operation.