[dev.icinga.com #617] check_mk failure in 1.0.2

[icinga-migration]

This issue has been migrated from Redmine: https://dev.icinga.com/issues/617

Created by mfriedrich on 2010-07-15 11:34:08 +00:00

Assignee: mfriedrich
Status: Resolved (closed on 2010-07-19 13:53:11 +00:00)
Target Version: 1.0.3
Last Update: 2010-07-19 13:53:11 +00:00 (in Redmine)

---

Regarding this discussion,

http://www.nagios-portal.org/wbb/index.php?page=Thread&threadID=19085

it was not the same bug as described on the mailinglists with check_nrpe and the command args - see #436 for further details.

The initial revision of execv in 1.0.2 misses extended error output, which is currently provided in mfriedrich/core testbranch.

The real problem which exists now is that executables/plugins within the PATH are not detected and the plugin call fails. E.g. for calling check_mk and Python.

define command {
  command_name  check-mk
  command_line  python /var/lib/check_mk/precompiled/$HOSTNAME$
}

A possible resolution would be to check which user runs execv and if PATH is set when explicitely calling execvp instead of execv (which is currently in GIT).

Changesets

2010-07-16 14:05:23 +00:00 by mfriedrich 67420d5

execvp searches in PATH too like popen, and returns if an error occurs, outputting the error string

revamped the previous attempt a bit. there might be discussions about
allowing PATH or not PATH env variables. But by completely breaking
compatibility this won't be nice.

the current attempt only checks if the first argument is set and then
calling execvp - this looks in $PATH if there is no trailing slash set
on the executable.
In case of an error, execvp returns -1 and this is where the error is
put into syslog, exiting with state unknown. (a further adaption would be
setting the output of the plugin like popen behaves)

if you consider not using the PATH for that, you can simply change execvp to
execv and recompile the code. The checks on executable/there are still valid,
except PATH lookups.

refs #436
refs #617

2010-08-09 16:39:26 +00:00 by mfriedrich 741601406428ca7666b8936b04d672561c49ce30

execvp searches in PATH too like popen, and returns if an error occurs, outputting the error string

revamped the previous attempt a bit. there might be discussions about
allowing PATH or not PATH env variables. But by completely breaking
compatibility this won't be nice.

the current attempt only checks if the first argument is set and then
calling execvp - this looks in $PATH if there is no trailing slash set
on the executable.
In case of an error, execvp returns -1 and this is where the error is
put into syslog, exiting with state unknown. (a further adaption would be
setting the output of the plugin like popen behaves)

if you consider not using the PATH for that, you can simply change execvp to
execv and recompile the code. The checks on executable/there are still valid,
except PATH lookups.

refs #436
refs #617

---

Relations:

• relates #436

[icinga-migration]

Updated by mfriedrich on 2010-07-15 14:04:31 +00:00

http://linux.die.net/man/3/execvp

The functions execlp() and execvp() will duplicate the actions of the shell in searching for an executable file if the specified filename does not contain a slash (/) character. The search path is the path specified in the environment by the PATH variable. If this variable isn't specified, the default path '':/bin:/usr/bin'' is used. In addition, certain errors are treated specially.

[icinga-migration]

Updated by mfriedrich on 2010-07-19 13:53:11 +00:00

• Status changed from New to Resolved
• Done % changed from 0 to 100

execvp works like expected, error msg are pointing to path too.