...

The node-centric actions (e.g. collect, update) are scheduled based on the node's last activity timestamps and its polling policy, which works the same as in NMIS8. Service checks are scheduled based on the service's period definition, again mostly unchanged from NMIS8.

When the Updates and Collects last occurred can be found using:

Fault-recovery

If a job remains stuck as active job for too long then the nmis daemon will abort it and reschedule a suitable new job. Such stuck jobs can appear in the queue if you terminate the nmis daemon with act=abort  or service nmis9d stop, because these actions immediately kill the relevant processes and don't take active operations into account.

...

NMIS also warns about unexpected queue states, e.g. if there are too many overdue queued jobs or if there are excessively many queued jobs altogether.

Parameters to prevent the queue getting too big

When the server has limited resources and cannot process the jobs in time, there is a risk of the jobs getting stacked in the queue. There are two configuration parameters that can help and can be set in Config.nmis:

• There was no default abort_plugins_after option in the configuration. This value can be added in Config.nmis:

  'overtime_schedule' => {
      'abort_plugins_after' => 7200, # Seconds
     ...
  }
  

• The schedule keeps adding these jobs into the queue. The workers can discard these jobs changing the configuration options postpone_clashing_schedule to 0.

  'postpone_clashing_schedule' => 0,
  

After theses two changes, nmis9d daemon needs to be restarted.

Interacting with the daemon using nmis-cli

...