I have lots of scripts, usually they start with a shebang and /usr/bin/env and the required interpreter (for example "#!/usr/bin/env perl"). This works fine since many years, but for some reason I don't understand I have one script on one FreeBSD machine where this breaks sudo:

% cat test.pl
#!/usr/bin/env perl
system( "id" );
exit 0;

Executing this as user nagios works fine. Executing this with sudo as user nagios also works fine.

But, executing this through nrpe daemon from monitoring server, where the nrpe is running as user nagios and using sudo as command_prefix it exits with error code 3. Since nrpe doesn't show any reasons, but just the exit code, I have no clue why this doesn't work. (Yes, sudo seems to be configured correctly to allow /usr/bin/env and test.pl, as it works on commandline)

nrpe[50742]: Running command: /usr/local/bin/sudo /usr/local/etc/nagios/test.pl
nrpe[50742]: Command completed with return code 3 and output: 
nrpe[50742]: Return Code: 3, Output: NRPE: Unable to read output

Yes, I could change the shebang string to /usr/local/bin/perl, which then works with sudo through nrpe, but the script is intended to be generic for different OS types.

So, any idea what I'm missing here?

  • 2
    Does the PATH produced by sudo include /usr/local/bin? Run sudo env | grep PATH to see... – Stephen Kitt May 15 at 11:47
  • Yes it does. server% id uid=181(nagios) gid=181(nagios) groups=181(nagios) server% sudo env |grep PATH PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/var/spool/nagios/bin – frank42 May 15 at 12:09
  • The phrase "one script on one FreeBSD machine" stands out to me. Do you have other perl scripts running in the same way on the same host? The first thing to debug is whether or not you are getting through to a working perl interpreter. Eg: try running a hello world. – Philip Couling May 15 at 13:19
  • 1
    @frank42 Yes that's generally clear, the very specific point that's not clear is where the point of failure is. If the full stack of nrpe,env, sudo, perl can togeather execute a perl script (even just "hello world") Then the point of failure is inside the script itself. The fact that the script runs from the command line might be misleading because any number of environment differences (including environment variables, CWD etc.) might be to blame for causing the script itself to fail. – Philip Couling May 15 at 15:18
  • 1
    @frank42 yes I really do understand the point of your question but you've missed a the very critical point that point of failure and the root cause may be very different. The little evidence you've provided proves that the root cause is not in the perl script but it does NOT prove the same about the point of failure. With zero evidence of what's wrong, your best option is a kind of binary search to what works and what doesn't. Step one in that binary search is to check if this stack can run any python script at all. – Philip Couling May 15 at 15:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.