This article explains an issue where the RE CPU spikes up on SRX due to cscript process.

You might see high RE CPU utilisation on SRX managed by MIST and when you try checking the process utilising most of the CPU, CSCRIPT process will be the one at the top. This process is responsible for running the scripts on the firewall and you must know devices which are managed by MIST have many scripts running for the monitoring purpose.

RE CPU status will show 0% idle, as shown below:

user@srx> show chassis routing-engine no-forwarding

Routing Engine status:
Temperature         34 degrees C / 93 degrees F
CPU temperature       65 degrees C / 149 degrees F
Total memory       4096 MB Max 2294 MB used ( 56 percent)
Control plane memory  2320 MB Max 1299 MB used ( 56 percent)
Data plane memory    1776 MB Max 1012 MB used ( 57 percent)
5 sec CPU utilization:
User           76 percent
Background         0 percent
Kernel          23 percent
Interrupt         0 percent
Idle            0 percent>>>>>>>>>>>>>>>>>>>>

Top command will show CSCRIPT utilising the most of the CPU, as shown below:

user@srx> show system processes extensive
node0:
--------------------------------------------------------------------------
last pid: 4170; load averages: 1.39, 1.37, 1.33 up 460+02:56:54  21:14:58
235 processes: 24 running, 196 sleeping, 1 zombie, 14 waiting
Mem: 1050M Active, 497M Inact, 1948M Wired, 262M Cache, 112M Buf, 207M Free
Swap: 792M Total, 792M Free
PID USERNAME PRI NICE SIZE  RES STATE C TIME WCPU COMMAND
2056 root  123  0 1945M 1214M CPU1 1  ??? 93.21% flowd_octeon_hm
24519 root  123  0 71376K 31048K RUN  0 187.7H 76.66% cscript >>>>>>>>>>>>>
2056 root   26  0 1945M 1214M RUN  0  ??? 6.74% flowd_octeon_hm

If you check the PID of the extension service, it will be same as the cscript PID displayed in the above output:

user@srx> show extension-service status all | no-more Extension service application details: 

Name : mxoc_agentd 
Process-id: 24519 >>>>>>>>>>>>>
Stack-Segment-Size: 8388608B 
Data-Segment-Size: 134217728B

You will see below given logs in the /var/log/mist log file:

2025-05-21 07:19:49,869,869 MXOC ERROR [event_subscriber] [run] Invalid EVT_RESPONSE_MSG_VERSION: 942551856
2025-05-21 07:19:49,870,870 MXOC ERROR [event_subscriber] [run] Invalid EVT_RESPONSE_MSG_VERSION: 2017272375
2025-05-21 07:19:49,871,871 MXOC ERROR [event_subscriber] [run] Invalid EVT_RESPONSE_MSG_VERSION: 1114795873
2025-05-21 07:19:49,872,872 MXOC ERROR [event_subscriber] [run] Invalid EVT_RESPONSE_MSG_VERSION: 1562403172
2025-05-21 07:19:49,873,873 MXOC ERROR [event_subscriber] [run] Invalid EVT_RESPONSE_MSG_VERSION: 778462766

These are the incorrectly synced events going from SRX to MIST pyagent causing the spike in the RE CPU.

If all the symptoms match, you can go ahead and kill the cscript process from SRX shell, as shown below:

user@SRX:~ # ps -aux | grep cscript

user  24540  0.0 0.6  69176  26332 - I  10Mar25   8:27.10 /usr/libexec/ui/cscript -mjet -Q3 -j -f mxoc_agentd.py -Tmxoc_agentd.log -Nall -Jroot

user  61565  0.0 0.0   524   324 0 R+  07:58    0:00.00 grep cscript

root@SRX:~ # kill 24540

user@SRX:~ # ps -aux | grep cscript

user  61580 19.2 0.8  54904  32140 - S  07:59    0:00.52 /usr/libexec/ui/cscript -mjet -Q3 -j -f mxoc_agentd.py -Tmxoc_agentd.log -Nall -Jroot

user  61606  0.0 0.0   524   324 0 R+  07:59    0:00.00 grep cscript

Please note that this issue has been fixed in pyagent version v0.1.722.