This article covers how a specific process can be restarted in Junos OS without rebooting the router. 

To restart a specific process, first, find out which processes are running by using the CLI command show system process from operational mode.

root@Router> show system processes extensive | match kmd
10020 root       2   0  6008K  4816K select   0:00  0.00%  0.00% kmd

In this example, we will restart the Key Management Daemon (kmd), which is responsible for running IPSec.

root@Router> restart ipsec-key-management immediately

Issue the CLI command show system process from operational mode again.

root@Router> show system processes extensive | match kmd   
10215 root       2   0  6008K  4792K select   0:00 10.15%  1.42% kmd

In the example above, you can see that the Process ID (pid) has changed after the restart from 10020 to 10215. The pid changes to a new one once the process is restarted.

You can also restart a process from shell mode too.

> start shell user root
Password:

Enter the root password. When you are in shell mode, enter the process that you want to restart.

For example, you want to restart the alarmd process.

root@SRX1:~ # ps -aux | grep alarmd
USER    PID  %CPU %MEM    VSZ   RSS TT  STAT STARTED      TIME COMMAND
root   6644  0.0  1.2 739672 11068  -  S    03:47     0:08.78 /usr/sbin/alarmd -N

Kill the process ID (6644 in this example) by using the following command:

root@SRX1:~ # kill -9 6644

Issue the shell mode command " ps -aux | grep alarmd" again.

root@srx1% ps -aux | grep alarmd
root    1161  0.0  0.2  6820  3500  ??  S     4:49AM   0:04.69 /usr/sbin/alarmd -N

In the example above, you can see that the Process ID (pid) has changed after the restart from 6644 to 1161. The pid changes to a new one once the process is restarted.

The third option to restart a process is by using the CLI command "request system process terminate <PID>" 

root@Router> show system processes extensive | match ssh
90215 root       2   0  1008K  1792K select   0:00 10.15%  1.42% sshd

> request system process terminate 10215 

root@Router> show system processes extensive | match ssh
90411 root       2   0  1008K  1792K select   0:00 10.15%  1.40% sshd

--> Additional information about SIGHUP and SIGHKILL:

SIGHUP on Junos

General Behavior

On Junos, SIGHUP (signal 1) usually triggers a graceful daemon restart or configuration reload, depending on the process.

Most Junos processes are monitored by:

• jsrpd
• eventd
• mgd (config management daemon)
• chassisd (hardware control)
• rpd (routing protocols)
• pfed, dfwd, etc.

When a daemon receives SIGHUP:

• It does not crash and is not forcibly terminated.
• The daemon handles the request internally:
  • Reloads configuration
  • Resets internal state
  • Re-reads files (keys, policies, configs)
  • Sometimes reinitializes subsystems

Examples in Junos

• rpd on SIGHUP: reloads routing policies or configuration without a full restart.
• mgd on SIGHUP: reloads management environment.
• chassisd on SIGHUP: reloads chassis/hardware inventory.
  
  

Junos guarantees

• A SIGHUP should not cause a routing flap.
• Control-plane protocols generally remain stable.
• The Process Manager tracks the daemon but does not take corrective action unless the process crashes.

SIGKILL on Junos

General Behavior

SIGKILL (signal 9) forcefully terminates the process immediately.

On Junos:

• The daemon cannot catch or ignore it.
• The Junos Process Manager detects the termination.
• The Process Manager will automatically restart the daemon to maintain system operation.
  
  

Effects on Junos

Force-killing a daemon can produce:

• Short-lived control plane interruption
• Protocol sessions resetting (if rpd is killed)
• Hardware programming pauses (if pfed or dfwd are killed)
• Temporary loss of CLI access (if mgd is killed)
  
  

Examples

• Killing rpd may cause:
  • Routing adjacencies to drop
  • BGP/OSPF/ISIS flaps
  • FIB/route recalculation
• Killing chassisd may:
  • Temporarily disrupt hardware monitoring
  • Trigger alarms until the daemon restarts
• Killing pfed (Packet Forwarding Engine daemon) may cause:
  • Traffic interruption
  • Hardware programming reset
  • PFE microkernel restart depending on conditions

Sending SIGHUP to a Junos daemon is safe.

It is commonly used for:

• Reloading configs
• Refreshing daemon state
• Resetting monitoring subsystems
  Without causing downtime.
  
  

Sending SIGKILL should only be done under TAC guidance.

It can cause:

• Routing adjacencies to drop
• Traffic interruption
• FPC/PFE resets
• Unstable control-plane behavior

2020-06-30: Article now covers restarting a process from CLI as well as shell mode. This article is complete and accurate. '

2024-12-27 : Added a third option to restart a process or terminate an existing process