Description
diagnose sys top <refresh interval> <max # of lines> <iterations>
The above command can be run as-is (diagnose sys top) or it can be run with additional parameters to adjust the refresh rate of the data (default is 5 seconds), how many lines are displayed (default is 20), and the number of iterations that should be run (default is unlimited). For example the following version of the command displays up to 200 processes every 10 seconds for 3 iterations:
diagnose sys top 10 200 3
Additionally, the output of the top command can be sorted in certain ways:
- Hit the 'p' key to sort processes by CPU usage.
- Hit the 'm' key to sort by memory usage.
- Hit the 'n' key to sort by process ID value (very useful when gathering a sorted list of all processes running on the FortiGate).
Finally, the column output of top can be interpreted as follows:
![](/legacyfs/online/images/kb_20908_1.png)
- Do not kill this process manually, as it will cause an outage for FortiGate interfaces connected to the internal ISF until a system reboot is conducted.
bgpd: Handles the Border Gateway Protocol (BGP) dynamic routing protocol; part of the ZebOS Routing Daemons.
- Notably, bgpd handles IPv4 and IPv6 within a single daemon (as opposed to RIP and OSPF having separate IPv4 and IPv6 daemons).
cfmd: Connectivity Fault Management daemon; useful for diagnosing/resolving issues within Ethernet networks (when configured).
- Introduced in FortiOS 7.4.1 as part of Change #765007. See also: Connectivity Fault Management
- Prior to 7.2.0, this daemon was named src-vis (it has since been renamed/updated as of Change #740250).
- Was previously named nstd, and was renamed/rebranded as of FortiOS 5.4.1 (per Change #308676).
- In FortiOS 6.4 and earlier, dnsproxy was always handling DNS traffic in a proxy-like fashion (even when performing flow-based inspection). In FortiOS 7.0 and later, DNS Filter duty is now handled by the IPS Engine see also: DNS filter handled by IPS engine in flow mode
- Previously, FortiAnalyzer and FortiGate-Cloud logging functionality was handled within miglogd. As of FortiOS 7.2.0 and later, fgtlogd is a new daemon that subscribes to miglogd's log publishing functionality and handles logging functionality to Fortinet-proprietary logging destinations (per Change #687202).
- Introduced in FortiOS 5.4.1 (per Change #188261)
- ikecryptd spawns a main manager process along with multiple child worker processes. These can be seen in the output of diagnose sys top-fd 100 | grep ikecryptd, where the child processes will be named 'ikecryptd_dhwX'
- Debug information for this process can be printed using diagnose vpn ikecrypt info.
- This process can also be further configured under config system ike in the CLI. Refer to the following for more information: CLI Reference (config system ike)
- Process may be disabled by default when upgrading from FortiOS 6.4 and earlier to FortiOS 7.0+. The option set dh-multiprocess will enable/disable the usage of ikecryptd.
- Introduced in FortiOS 6.4.0 (per Change #607855) and ties into the IoT Detection subscription service available on FortiGates (see also: IoT detection service).
- One of the ipsengine workers will have a 'master:1' flag signifying it as the master engine. The master ipsengine handles additional tasks, such as cleaning up SSL cache entries and updating signature databases on the Content Processor.
- Also handles the compilation of the IPS rule database and generating DFA entries for upload to the Content Processor (if present).
ipsmonitor: Oversees ipsengine workers and serves as a watchdog, starting/stopping/restarting engines as required.
- Restarting ipsmonitor with diag test app ipsmonitor 99 gracefully restarts all ipsengine processes with no disruption to flow-based traffic sessions.
- Frequently pairs with iked process for L2TP over IPsec remote-access VPN tunnels (see also: L2TP over IPsec)
lldprx: Handles receiving (rx) of Link-Layer Discovery Protocol traffic on the FortiGate.
lldptx: Handles transmitting (tx) of Link-Layer Discovery Protocol traffic on the FortiGate.
- First introduced in FortiOS 5.2 (per Change #224654). Before this, FortiOS could only receive LLDP frames and not transmit/advertise them.
- Previously, local logging functionality was handled within miglogd. As of FortiOS 7.2.4 and later, locallogd is a new daemon that subscribes to miglogd's log publishing functionality and handles local logging functionality (per Change #687201 and also #892541).
- kmiglogd: the Kernel Log Daemon
- In FortiOS 6.4.2 and later, miglogd's complex functionality was divided amongst multiple separate daemons. The main miglogd process now solely handles the building and publishing of log messages, and other daemons subscribe to miglogd to utilize these published logs (per Change #584449).
- See here for more information on the function of the node daemon and some causes for high memory usage by the process: Technical Tip: High memory usage of node process
- Was removed from FortiOS as of version 6.2.4 and 6.4.0 (see Resolved Issue #599284).
- See also: Technical Tip: pyfcgid (python config daemon) entry in FortiGate crash log
- As of FortiOS 6.4.2 and later, reportd is a subscriber daemon to logs published by miglogd (per Change #584449).
- Renamed/replaced by the cid daemon as of FortiOS 7.2.0 and later (per Change #740250).
- Previously, syslog functionality was handled within miglogd. As of FortiOS 7.0.0 and later, syslogd is a new daemon that subscribes to miglogd's log publishing functionality and handles syslog-based logging functionality (per Change #665697).
- This process also fully replaces the older rlogd process.
- As of FortiOS 6.2.1 and later, multiple urlfilter daemons can be spawned as a worker processes managed by the wf_monitor daemon (per Change #526481).
- Prior to FortiOS 6.2.1, urlfilter was a single-process daemon. Enabling multiple urlfilter worker processes has resulted in substantial increases in total performance.
- In FortiOS 6.4 and earlier, voipd handled SIP traffic in a proxy-based manner, regardless of the inspection-mode. In FortiOS 7.0 and later, flow-based SIP inspection is handled by the IPS Engine (see also: https://docs.fortinet.com/document/fortigate/7.0.0/new-features/644799/flow-based-sip-inspection)
- In FortiOS 6.0 and earlier, inspection modes were set on a per-VDOM or global basis. In FortiOS 6.2.1 and later, it became possible to set Firewall Policies to be either flow-based or proxy-based, which results in traffic largely being inspected by the IPS Engine or WAD respectively (see: https://docs.fortinet.com/document/fortigate/6.2.0/new-features/497716/flow-versus-proxy-policy-impr...)
- Refer to the following KB article for more in-depth information regarding the various sub-processes of WAD: Technical Tip: Overview of WAD process structure
wf_monitor: Web Filter monitor daemon (parent to urlfilter daemon). New daemon that was introduced as part of new multi-process urlfilter project that aimed to improve performance. Introduced in FortiOS 6.2.1 and later (per Change #526481).
- The wf_monitor daemon is responsible for starting, restarting, and killing urlfilter worker processes; monitor worker statuses and gather debugging statistics; and manage shared memory caches for urlfilter workers.
- This daemon enables multiple urlfilter worker processes, which improves Web Filtering performance by scaling across multiple CPU cores.
![](/legacyfs/online/images/kb_20908_2.png)
![](/legacyfs/online/images/kb_20908_3.png)
Some applications can be seen in the list of top processes and cannot be debugged or investigated in-depth, because the information may not serve in troubleshooting.
Related articles:
Technical Tip: How to list processes in FortiOS