| Description | This article provides a solution for an issue where the 'cmdbsrv' daemon on FortiGate devices experiences high CPU utilization (85% to 90%) for approximately 11 minutes after a reboot leading to temporary performance issues. |
| Scope | FortiGate v7.6.1. |
| Solution |
After rebooting the FortiGate, the 'cmdbsrv' daemon exhibits high CPU utilization, typically between 85% and 90%, for about 11 minutes. Once this period elapses, the CPU utilization of the 'cmdbsrv' daemon returns to normal. diagnose system top 2 50
After 11 Minutes:
This issue has been resolved in v7.6.3 (available in the support portal).
Another example is repeated and frequent CMDB_REQ_COMMIT requests that related to the 'cmdbsvr' process.
diag debug reset diag debug cmdb-trace 1 diag debug console timestamp enable diag debug enable diag sys top-mem 30
2025-04-24 10:05:26 cmdbsvr set_in_by_cmdbsvr 2025-04-24 10:05:26 cmdbsvr set_iprope 2025-04-24 10:05:28 cmdbsvr recv req_type=0(CMDB_REQ_COMMIT) from pid=18267(/bin/dhcpcd) 2025-04-24 10:05:28 [_svr_d_commit:2703] pid=18267, object='system.interface' 2025-04-24 10:05:28 cmdbsvr recv req_type=0(CMDB_REQ_COMMIT) from pid=18267(/bin/dhcpcd) 2025-04-24 10:05:28 [_svr_d_commit:2703] pid=18267, object='system.interface' 2025-04-24 10:05:28 cmdbsvr recv req_type=0(CMDB_REQ_COMMIT) from pid=18267(/bin/dhcpcd) 2025-04-24 10:05:28 [_svr_d_commit:2703] pid=18267, object='router.static' 2025-04-24 08:05:28 cmdbsvr starting: pid=18274, argc=1, argv[1]='' 2025-04-24 10:05:30 cmdbsvr set_iprope6 2025-04-24 10:05:32 cmdbsvr waiting for request... 2025-04-24 10:05:32 cmdbsvr set_in_by_cmdbsvr 2025-04-24 10:05:32 cmdbsvr set_iprope 2025-04-24 10:05:33 cmdbsvr recv req_type=0(CMDB_REQ_COMMIT) from pid=18277(/bin/dhcpcd) 2025-04-24 10:05:33 [_svr_d_commit:2703] pid=18277, object='system.interface' 2025-04-24 10:05:35 cmdbsvr recv req_type=0(CMDB_REQ_COMMIT) from pid=18277(/bin/dhcpcd) 2025-04-24 10:05:35 [_svr_d_commit:2703] pid=18277, object='system.interface' 2025-04-24 10:05:35 cmdbsvr recv req_type=0(CMDB_REQ_COMMIT) from pid=18277(/bin/dhcpcd) 2025-04-24 10:05:35 [_svr_d_commit:2703] pid=18277, object='router.static' 2025-04-24 08:05:35 cmdbsvr starting: pid=18284, argc=1, argv[1]='' 2025-04-24 10:05:38 cmdbsvr waiting for request... 2025-04-24 10:05:38 cmdbsvr set_in_by_cmdbsvr 2025-04-24 10:05:38 cmdbsvr set_iprope 2025-04-24 10:05:40 cmdbsvr recv req_type=0(CMDB_REQ_COMMIT) from pid=18286(/bin/dhcpcd) 2025-04-24 10:05:40 [_svr_d_commit:2703] pid=18286, object='system.interface' 2025-04-24 10:05:41 cmdbsvr set_iprope6 2025-04-24 10:05:52 cmdbsvr recv req_type=0(CMDB_REQ_COMMIT) from pid=18286(/bin/dhcpcd) 2025-04-24 10:05:52 [_svr_d_commit:2703] pid=18286, object='system.interface' 2025-04-24 10:05:52 cmdbsvr recv req_type=0(CMDB_REQ_COMMIT) from pid=18286(/bin/dhcpcd) 2025-04-24 10:05:52 [_svr_d_commit:2703] pid=18286, object='router.static' 2025-04-24 08:05:52 cmdbsvr starting: pid=18293, argc=1, argv[1]='' 2025-04-24 10:05:55 cmdbsvr waiting for request... 2025-04-24 10:05:56 cmdbsvr set_in_by_cmdbsvr
From the output above, frequent CMDB_REQ_COMMIT requests come from the dhcpcd process, specifically related to updates on system.interface and router.static objects.
These commits happen every few seconds, triggering cmdbsvr to commit changes repeatedly. Each new PID indicates a new dhcpcd process instance, suggesting it's being restarted repeatedly.
Solution:
Perform DHCP process debugs and check if there is any error showing in the process.
diagnose debug disable diagnose debug application dhcpd -1 diagnose debug enable
Keep the debugs running and disable the debugs from the following command:
diagnose debug disable
Kill the two top processes 'cmdbsvr' and 'dhcpd' using their process IDs, and then check the results on the CPU afterwards.
diagnose sys kill 11 77 <----- 77 is the process ID of dhcpd as seen from output diagnose sys top. diagnose sys kill 11 24578 <----- 24578 is the pid of cmdbsvr.
Note: Killing the process with signal 11 will result in an entry being added to the crashlog file.
General debug information is required by FortiGate TAC for investigation.
Workaround:
To instantly remediate the high CPU utilization due to cmdbsvr, the process can be killed using the command below.
fnsysctl killall cmdbsvr |
