Converting Icinga in LXC - > Icinga in LXD Container Station in QNAP

Icinga Monitoring Satelite has been running in Container Station from QNAP in LXC Instance for years without any problems.

Now LXC Container is deprecated and we moved everything to LXD Container with migration tool.

When we start LXD Container, Icinga runs without error messages (all configuration is identical like in LXC Container), but still notifications about devices followed by a Icinga satellite look like “DOWN”.
Has anybode some clue why that so is?

Hello, I’ve checked Logs from Icinga in LXC and Icinga in LXD, and only two Logs waren’t identical:

notice/WorkQueue: Spawning WorkQueue threads for ‘Js onRpcConnection, #1

notice/WorkQueue: Spawning WorkQueue threads for ‘Js onRpcConnection, #0

And one more Log:
notice/Process: PID 8169 (’/usr/lib/nagios/plugins/c heck_ping’ ‘-H’ ‘’ ‘-c’ ‘5000,100%’ ‘-t’ ‘5’ ‘-w’ ‘3000,80%’) term inated with exit code 0

notice/Process: PID 751 (’/usr/lib/nagios/plugins/check_ping’ ‘-H’ ‘’ ‘-c’ ‘900,15%’ ‘-t’ ‘5’ ‘-w’ ‘450,5%’) terminated with exit code 3

Does anyone know what “Js onRpcConnection, #0” and “terminated with exit code 3” mean?

JSON-RPC is the protocol of the cluster communication.

Exit code 3 of a plugin is unknown while 0 is ok, so unknown will translate to down for a host check.

1 Like


thank you very much for a reply. I’ve also thought that “exit code 3” nothing good is. Any clue, what to change in configuration in order that “exit code 0” again happen?

Can you attach to the container and run the check to get the output? Perhaps the output gives you a hint. My blind guess would be a networking problem.

Hello, do you mean this (Photo) or Linux Logs from Container?

container info

Hello, I’ve checked Network Connection on LXC and LXD and got this:

Also interesting is, when I start LXD, all Devices are “DOWN” except only couple of devices. Does anyone know why only some devices are still “UP”:

Could be some routing problem.

it’s possible, but all devices that are “DOWN” can Ping Icinga Srv in LXD and vice versa.New MAC Adress from Icinga Srv in LXD is in ARP Table from devices that “DOWN” are. When we see from Icinga Master one “DOWN” device, we see that this device available is, but
but can’t read ping.

Problem was: Device available, but Master can’t read Status from Ping.

Finally solution found: To add the cap_net_raw capability to (for eg /bin/ping), use the following command on Satelite:

#setcap cap_net_raw=ep /bin/ping