<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[NRPE3 process 100% CPU load]]></title><description><![CDATA[<p dir="auto">Hi,</p>
<p dir="auto">We run a CARP setup with two dedicated Xeon Servers and pfSense 2.5.1.<br />
For HA there's a dedicated 1G copper link. Everything else is connected over 2 times 10G LACP. For every downstream interface there's a VLAN interface on top of that LAGG.<br />
We're monitoring both nodes with Icinga2 and NRPE individually. We recently switched from Nagios to Icinga2 and also from IPv4 addresses to IPv6 addresses. The problem started occuring after this switch.</p>
<p dir="auto">Only the secondary device suffers from the problem that the NRPE3 process itself after a couple of minutes takes 100% CPU load. After some more time even more NRPE processes spawn, also with 100% CPU load. After few hours load goes higher than 5. Never waited much longer but I guess it's a neverending story.</p>
<p dir="auto"><img src="/assets/uploads/files/1638454461389-pfsense_nrpe.png" alt="pfsense_nrpe.png" class=" img-fluid img-markdown" /></p>
<p dir="auto">NRPE process looks like this:</p>
<pre><code>nagios  36022 100.0  0.0  16144  6192  -  R    13:40       7:27.85 /usr/local/sbin/nrpe3 -d -c /usr/local/etc/nrpe.cfg
</code></pre>
<p dir="auto">config file looks like this:</p>
<pre><code>log_facility=daemon
pid_file=/var/run/nrpe3.pid
server_port=5666
nrpe_user=nagios
nrpe_group=nagios
allowed_hosts=2a00:1234:0:106::61
dont_blame_nrpe=0
debug=0
command_timeout=60
connection_timeout=300
command[check_users]=/usr/local/libexec/nagios/check_users -w 5 -c 10 
command[check_load]=/usr/local/libexec/nagios/check_load -w 15,10,5 -c 30,25,20 
command[check_root]=/usr/local/libexec/nagios/check_disk -w 20% -c 10% -p /
command[check_var]=/usr/local/libexec/nagios/check_disk -w 20% -c 10% -p /var/run
command[check_zombie_procs]=/usr/local/libexec/nagios/check_procs -w 5 -c 10 -s Z
command[check_total_procs]=/usr/local/libexec/nagios/check_procs -w 150 -c 200 
command[check_swap]=/usr/local/libexec/nagios/check_swap -w 50% -c 25% 
command[check_synclink]=/usr/local/libexec/nagios/check_ping -w 10,2% -c 20,5% -H 192.168.15.2
server_address=2a00:1234:0:16::3
</code></pre>
<p dir="auto">It looks like sometimes the icinga2 daemon gets a timeout when connecting to the nrpe process and it somehow looks like at that event a new nrpe3 process is being spawned.<br />
I wasn't able to find anything related to that.</p>
]]></description><link>https://forum.netgate.com/topic/168257/nrpe3-process-100-cpu-load</link><generator>RSS for Node</generator><lastBuildDate>Sat, 18 Apr 2026 17:16:40 GMT</lastBuildDate><atom:link href="https://forum.netgate.com/topic/168257.rss" rel="self" type="application/rss+xml"/><pubDate>Thu, 02 Dec 2021 14:24:28 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to NRPE3 process 100% CPU load on Thu, 02 Dec 2021 21:53:38 GMT]]></title><description><![CDATA[<p dir="auto">You could be hitting the route-to/reply-to bug that was fixed in 2.5.2:<br />
https://docs.netgate.com/pfsense/en/latest/releases/2-5-2.html#rules-nat<br />
https://redmine.pfsense.org/issues/11805</p>
<p dir="auto">Though I agree the nrpe service should not behave like that. That's probably an upstream bug though.</p>
<p dir="auto">Steve</p>
]]></description><link>https://forum.netgate.com/post/1012864</link><guid isPermaLink="true">https://forum.netgate.com/post/1012864</guid><dc:creator><![CDATA[stephenw10]]></dc:creator><pubDate>Thu, 02 Dec 2021 21:53:38 GMT</pubDate></item><item><title><![CDATA[Reply to NRPE3 process 100% CPU load on Thu, 02 Dec 2021 16:11:48 GMT]]></title><description><![CDATA[<p dir="auto">Update:<br />
It seems there is an asymmetric routing problem which leads to this phenomenon. TCP Sessions die because of that after 30 seconds. We will fix this by using a different IPv6 address for the check.</p>
<p dir="auto">Yet I believe this should never lead to the nrpe service going haywire.</p>
]]></description><link>https://forum.netgate.com/post/1012817</link><guid isPermaLink="true">https://forum.netgate.com/post/1012817</guid><dc:creator><![CDATA[junicast]]></dc:creator><pubDate>Thu, 02 Dec 2021 16:11:48 GMT</pubDate></item></channel></rss>