I’d assume you run it directly as user root and this different to the execution by the agent since the agent runs as user icinga. And most properly the user icinga does not have enough rights. You can verify this by switching to user icinga sudo -u icinga bash and executing the check.
I’m not familiar with CentOS and maybe this has something to do with SELinux.
As @rsx wrote maybe SELinux causing a problem. If you try this command
sestatus
You will see if enabled or disabled.
If enabled and you try this command in one bash
tail -f /var/log/audit/audit.log | grep -i denied
and trigger the check in another bash or web you’ll should immediately if SELinux blocks something.
If you didn’t enabled SELinux you have to go deeper. Because we havent’ installed check_uptime for CentOS, you could pls tell us which check this is? I only found in our ITL only the version for Windows.
Thank you @rsx and @stevie-sy for the advice. Found the problem.
So when I ran the command, in it’s most basic form, check_uptime, it worked fine. Returned Uptime: OK. The issue is when I can the command with variables. It seems that the moment I use variables to define what is determined as Warn or Crit, it simply returns Uptime: CRITICAL regardless of the value.
So the fix was to create a new Command in Directory, and remove the variables from it, and then use that to apply to my CentOS hosts.
Really strange problem to have, but I suppose it’s a workaround until it’s raised as a bug I guess? If it even is a bug?