check_procs error: wmax (250) cannot be greater than cmax (10)

This forum was archived to /woltlab and is now in read-only mode. Please register a new account on our new community platform.

You can create a thread on the new site and link to an archived thread. This archive is available as knowledge base, safe and secured.

More details here.
  • Hi,

    recently I moved some of my checks from NRPE to Icinga2 client. Here's one check which fails with very strange message.

    Check itself:

    Here's the output of the check:

    1. wmax (250) cannot be greater than cmax (10)
    2. check_procs: Could not parse arguments
    3. Usage:
    4. check_procs -w <range> -c <range> [-m metric] [-s state] [-p ppid]
    5. [-u user] [-r rss] [-z vsz] [-P %cpu] [-a argument-array]
    6. [-C command] [-t timeout] [-v]

    Same check in same env on other hosts works fine, just on the master on one env, and on satellite on another env it doesn't work. Any idea what could be wrong?

    I don't set `vars.procs_warning` anywhere

  • 250 is set in the template "/usr/share/icinga2/include/command-plugins.conf"

    Just set "vars.procs_warning" to the same value like "vars.procs_critical".

  • It's set in template on all hosts, but I have issues only on master and satellite, other satellites and clients don't have that issue.

  • Can you please show a host config ?

    Just set "vars.procs_warning" to the same value like "vars.procs_critical".

    This has to be done in the service definition.

  • I understand that, but why it works on other hosts without setting it vars.procs_warning?

    Non-working host config:

    1. object Host "ops-monmaster1" {
    2. import "linux-box-remote"
    3. address = ""
    4. }

    Working host config:

    1. object Host "de-staging-mon1" {
    2. import "linux-box-remote"
    3. address = ""
    4. vars.fs_thresholds = "/var/backups/bacula:5:10"
    5. vars.ext_address = ""
    6. vars.grafana_address = ""
    7. }
  • birkch custom attributes can also be specified on the host object. The lookup order of runtime macros helps here, first command -> host -> service. Service always wins. Still there is a use case for defining such on the service level - you can see those thresholds inside Icinga Web 2 in the detail view.

  • Hi @all

    i took over this problem for our company (:
    so... in service definition we've defined only vars.procs_critical. I assume there is some default vars.procs_warning. I'll try to test it now. But maybe someone can point me for default value of this parameter?

    nvm. found default value.

    The post was edited 1 time, last by l13t ().

  • Ok. Topic could be closed I think. We forgot about setting up warning after migration to icinga agent from nrpe.

    I assume the logic of check_procs call in agent was changed and if warning is not defined it's forced to be 250 what breaks our setup.