The article explains the reason behind taking longer times to execute the command restart routing after its issued.
restart routing taking longer times to restart the process is expected when RPD is already running at higher CPU cycles.
if RPD doesn't respond for the SIGTERM .. process/application waits for the 90 sec before performing SIGKILL.
With SIGKILL, RPD will be forced to terminate and spawn the new PID.
When RPD was busy (for some reason), so the signal "restart routing" did reached RPD however as its busy there was no response. Hence after 90 sec SIGKILL has been performed.
The following messages indicate that RPD was busy and unresponsive much before .. and these messages were continued till RPD was killed by SIGTERM.
Apr 18 19:21:09.486 router mgd[15433]: UI_OPEN_TIMEOUT: Timeout connecting to peer 'routing'Apr 18 19:21:10.275 router mgd[15871]: UI_OPEN_TIMEOUT: Timeout connecting to peer 'routing'Apr 18 19:21:20.832 router mgd[19331]: UI_OPEN_TIMEOUT: Timeout connecting to peer 'routing'Apr 18 19:21:24.387 router mgd[15871]: UI_OPEN_TIMEOUT: Timeout connecting to peer 'routing'
The symptoms that RPD is already running high, can be observed either by looking at ,
show system processes extensive | match rpdorfrom show log messages,Apr 18 19:21:09.486 router mgd[15433]: UI_OPEN_TIMEOUT: Timeout connecting to peer 'routing'Apr 18 19:21:10.275 router mgd[15871]: UI_OPEN_TIMEOUT: Timeout connecting to peer 'routing'Apr 18 19:21:20.832 router mgd[19331]: UI_OPEN_TIMEOUT: Timeout connecting to peer 'routing'Apr 18 19:21:24.387 router mgd[15871]: UI_OPEN_TIMEOUT: Timeout connecting to peer 'routing'
This is informational article,