0

I continually receive error in title. (see picture) nagios image

However, I have given my sh script all permissions (chmod 777 with nagios as owner). My script also works fine on a nagios core container but with a nagios xi docker container, it messes up.

Here is the permissions on my script in the picture for proof: permissions

The command also works on the the UI if I manually call it in the service management section of nagios.

Command also works using nagios user to run script nagios user running script

Docker container I am using: https://hub.docker.com/r/mavenquist/nagios-xi

I've tried using this post's solutions: Nagios: return code of 13 is out of bounds

1 Answers1

0

It's not entirely possible to answer your question completely with the information provided, but here are some pointers:

  • Never set 777 permissions. In your case the owner of the script is already "nagios:nagios" so a more reasonable permission would be 550 -- i.e. allow the nagios user and group to read and execute the file, but not modify it (why would it).

  • The error you're getting (return code 13) means that 1.sh for some reason is returning 13. Why is impossible to know without inspecting the script, but you can try to run the plugin as nagios and inspect the output, hopefully the script is well written enough to inform you of what the error is:

# su -c "/your/plugin -exactly -as -configured" nagios

A general rule for troubleshooting Nagios is that whatever you see in the GUI will be the exact same thing as what happens when you run the script manually as the nagios user, so it's a good way to figure out what is happening.

pzkpfw
  • 565
  • 3
  • 21
  • What's different when I'm running it manually is that I need to specify the macros. These scripts work perfectly with nagios core. I'm wondering then if the problem is if the docker image I'm using for nagios XI has a bug. Also, I do understand the 777 permission but this is running inside a container in a development environment, not production. – unknownexplorer Jun 27 '22 at 12:48
  • The command works perfectly running with nagios permissions as well. See updated post. – unknownexplorer Jun 27 '22 at 13:12
  • That the command "works" is a question of definition, run the plugin, then `echo $?` immediately afterwards, what is the exit code? I would expect it to return 13 since there is nothing fundamentally different from how Nagios itself should be running the command. – pzkpfw Jun 27 '22 at 14:09
  • Also, you can inspect the shell script itself (or the command) and try to understand in what situations it would throw exit code 13, and backtrack from there why it's happening. It's being given by the script/binary/whatever, it's not something Nagios is making up. It looks a shell script running curl? If the exit code is returned by curl, Google says it means `13="FTP weird PASV reply, Curl couldn't parse the reply sent to the PASV request."` -- but the meaning could be anything depending on what is returning it – pzkpfw Jun 27 '22 at 14:12
  • the command you provided echos out 0. I'm very confused. Could it be that the docker image itself has some sort of problem? – unknownexplorer Jun 27 '22 at 14:37
  • Also in my script I've only defined scenarios to return 0-3, the 4 exit codes that nagios recommends to provide. What I've mentioned preciously that I find odd is that a nagios-core docker image works fine with my script but the nagios-xi image has issues. – unknownexplorer Jun 27 '22 at 14:39
  • I've also tried to simply return 0 at the start of the script but it still outputs the same error @pzkpfw – unknownexplorer Jun 27 '22 at 14:41
  • Supply exact commands and output. – pzkpfw Jun 29 '22 at 15:41