Skip to main content
Question

Issue after migration (EL to Debian) – Timeout NRPE & SNMP

  • June 17, 2026
  • 2 replies
  • 8 views
R
Forum|alt.badge.img+5

Hi,

Following the migration of our Centreon server from Alma 9 to Debian 12, we are experiencing consistent timeout issues when monitoring a Windows VM and a storage array.

The Windows VM has refused to respond correctly to requests since the migration:

NRPE (Job-Status): The NRPE version ping works remotely (‘I (0.11.8 2026-01-24) seem to be doing fine...’), but as soon as I call a script, I get a ‘Process Timeout’ (and ‘0 bytes received’ in the CLI). However, the centreon_plugins.exe plugin runs fine when launched locally.

SNMP side: Windows SNMP check commands consistently time out when run from Centreon:

The Swap service reports: UNKNOWN: SNMP GET Request: Timeout

The Memory service reports: UNKNOWN: SNMP Table Request: Timeout

sudo -u centreon-engine /usr/lib/centreon/plugins//centreon_windows_snmp.pl --plugin=os::windows::snmp::plugin --mode=swap --hostname=IP --snmp-version=“2c” --snmp-community=“public” --warning=“80” --critical=“90”

 

The storage array and the Hardware services (CTRL1 and CTRL2) also report: UNKNOWN: SNMP Table Request: Timeout.

However, the IP address of the new Centreon Debian 12 server has been successfully added and configured in the array’s authorisations (public community).

 

Thank you in advance for your help.

2 replies

R
Forum|alt.badge.img+5
  • RTFM
  • Author
  • Steward **
  • June 23, 2026

Does anyone have any ideas on how to solve this problem ?

R
Forum|alt.badge.img+5
  • RTFM
  • Author
  • Steward **
  • June 24, 2026

Storage array & Windows SNMP: Issues fully resolved (restarted the management controllers for the array, and added SNMPEXTRAOPTIONS --snmp-force-getnext for Windows).

Our final sticking point concerns the NRPE (Job-Status) service on a Windows VM (NSClient++ v0.11.x). The status remains ‘Unknown’ with the error :

CHECK_NRPE: Receive header underflow – only 0 bytes received (4 expected).

Our current configuration :

Centreon : Debian 12 (OpenSSL 3)

Target : Windows Server - Centreon IP address correctly authorised in the .ini file.

Already tested without success :

On the Windows side (nsclient.ini): Set `insecure = true` under [/settings/NRPE/server] and removed the `certificate` directive. The service was successfully restarted.

On the Centreon side (Macros): Tested the arguments -2 -P 8192 as well as plain text mode without SSL via -n (with a long timeout: -n -t 120).

Despite using ‘insecure’ mode on the agent side and ‘-n’ on the Centreon side, the socket is closed instantly (0 bytes received). However, the centreon_plugins.exe plugin runs perfectly well locally on Windows.

Has anyone managed to work around this behaviour related to the OpenSSL 3 stack in Debian 12 with NRPE ?

Thanks in advance.

Terms & ConditionsAccessibility statement