Execution of shell shell scripts by Centreon Engine

  • 21 March 2024
  • 4 replies



We often get issue with custom plugin (or event handlers) implemented in Bash as the behavior between running them manually from the shell behaves differently of when they’re run by the centengine process. I guess this is a normal behavior and related to the login/interactive nature of the shell, which differs in both cases.

Does someone is able to bring some precision on the method centengine uses to run the commands?

I’m not sure to understand the meaning of the following option in command configuration (picture pasted at the end of the post because it seems I can’t move it between text blocks):

Does the description mean it has no influence when using Centreon Engine?

Does centengine force the shell to be interactive (and thus loads some environment of the centreon-engine user? Or does it set some variables independently? What else?

I have to run some tests but I’d like to ask here if someone has any clue. Some users in our company have observed difference in the $PATH value between a central and a poller and values are both different of the profile value of centreon-engine.

I also noticed that (in RHEL 8) the PHP 8.1 package has a dependency on the package environment-module which offers a tool (not the simple kind of…) to get dynamic execution environment. It seems to be activated for php8.1 only, and maybe it’s another subject, but it may also have a link with the subject of this question(s). PHP being installed on the central only, if it changes the behavior of Centreon Engine between pollers and centrals this is an issue.

Something I’d like  to do also, if possible, is to know if I can manually run commands in the same conditions than when it’s the centengine daemon which runs them.

Have a nice day.


Best answer by deborah621 27 March 2024, 12:40

View original

4 replies

ERRATUM: Centreon depends on PHP (8.1 ?) but not on the php81-runtime packages specifically. Maybe it has been the case once, maybe the package has been installed for another (wrong) reason. It’s only this package that depends on the environment-modules package. So I’ll probably be able to uninstall it. 

The other interrogations I have remain.

If the best thing I could do is to have a look at the source, I’d appreciate some links to where exactly I should to to get answers.


Regarding the PHP 8.1 package dependency on the environment-module, this module allows for dynamic modification of the user environment via modules. It’s possible that this could affect the execution environment of PHP scripts, but it would not typically affect other processes unless they are specifically designed to interact with this module.

To run commands in the same conditions as the centengine daemon, you would need to simulate the same non-interactive environment. This could involve setting the same environment variables and $PATH as the centengine process uses. You can inspect the environment of the centengine process by looking at the /proc/[pid]/environ file, where [pid] is the process ID of centengine. This will give you a list of the environment variables that centengine is using.


Thank you for your response.

>affect the execution environment of PHP scripts, but it would not typically affect other processes

I’m not sure to really understand how it works exactly but there is a php81 module available and fact is the directory /usr/share/Modules is added in first position to the PATH of user centreon-engine. If the PHP FPM Apache module is affected I guess it could affect how command is run by centengine, because that’s Centreon’s PHP code that constructs the command which centengine then execute.

>unless they are specifically designed to interact with this module

Isn’t rather how the Modules program is configured (activation of different modules) that determines if there is an interaction. In our case the plugin script run by the engine is calling “psql” (the Postgres client) and while /usr/bin was part of the PATH we had this strange error:

could not find a "psql" to execute

could not find a "psql" to execute

psql: error: could not find own program executable

/usr/bin/psql being in the PATH. And my co-workers having the error noticed PATH was different between the poller (without Modules installed) and the central (with Modules installed). Setting the PATH directly in the script made the script works and I have no damned clue why.

Anyway let’s not lose time on this. What I think is important for Centreon to keep in mind is to never depends on this Modules tool, which is a real labyrinthine software for sure!

>you would need to simulate the same non-interactive environment. 

Yeah this is the idea. And environment isn’t the only condition that could differs, there are shell options too. Thanks for the /proc/<PID>/environ I didn’t think of it, that helps a lot. I’ll make some check/event_handler test scripts to see if I can spot some other settings. And eventually look at the centengine source too.
But I can already confirm the Modules (a priori), which is still installed on our production platform, on the central but not on the poller) does effectively not influence centengine execution environment, but it influences the environment of the shells it runs itself (ie: subshells). Logged as centreon-engine, if I run another shell (bash or sh), which is indeed interactive, but not a login shell, on the central with Modules installed I get this:

[centreon-engine@sr204032cti3700 ~]$ bash

bash-4.4$ cat /proc/$$/environ | tr '\0' '\n'





which_declare=declare -f


















LESSOPEN=||/usr/bin/ %s

BASH_FUNC_which%%=() {  ( alias;

 eval ${which_declare} ) | /usr/bin/which --tty-only --read-alias --read-functions --show-tilde --show-dot $@


BASH_FUNC_module%%=() {  _module_raw "$@" 2>&1


BASH_FUNC__module_raw%%=() {  unset _mlshdbg;

 if [ "${MODULES_SILENT_SHELL_DEBUG:-0}" = '1' ]; then

 case "$-" in


 set +vx;




 set +v;




 set +x;








 unset _mlre _mlIFS;

 if [ -n "${IFS+x}" ]; then



 IFS=' ';

 for _mlv in ${MODULES_RUN_QUARANTINE:-};


 if [ "${_mlv}" = "${_mlv##*[!A-Za-z0-9_]}" -a "${_mlv}" = "${_mlv#[0-9]}" ]; then

 if [ -n "`eval 'echo ${'$_mlv'+x}'`" ]; then

 _mlre="${_mlre:-}${_mlv}_modquar='`eval 'echo ${'$_mlv'}'`' ";



 _mlre="${_mlre:-}${_mlv}='`eval 'echo ${'$_mlrv':-}'`' ";



 if [ -n "${_mlre:-}" ]; then

 eval `eval ${_mlre} /usr/bin/tclsh /usr/share/Modules/libexec/modulecmd.tcl bash '"$@"'`;


 eval `/usr/bin/tclsh /usr/share/Modules/libexec/modulecmd.tcl bash "$@"`;



 if [ -n "${_mlIFS+x}" ]; then



 unset IFS;


 unset _mlre _mlv _mlrv _mlIFS;

 if [ -n "${_mlshdbg:-}" ]; then

 set -$_mlshdbg;


 unset _mlshdbg;

 return $_mlstatus


BASH_FUNC_switchml%%=() {  typeset swfound=1;

 if [ "${MODULES_USE_COMPAT_VERSION:-0}" = '1' ]; then

 typeset swname='main';

 if [ -e /usr/share/Modules/libexec/modulecmd.tcl ]; then

 typeset swfound=0;




 typeset swname='compatibility';

 if [ -e /usr/share/Modules/libexec/modulecmd-compat ]; then

 typeset swfound=0;





 if [ $swfound -eq 0 ]; then

 echo "Switching to Modules $swname version";

 source /usr/share/Modules/init/bash;


 echo "Cannot switch to Modules $swname version, command not found";

 return 1;



BASH_FUNC_scl%%=() {  if [ "$1" = "load" -o "$1" = "unload" ]; then

 eval "module $@";


 /usr/bin/scl "$@";



BASH_FUNC_ml%%=() {  module ml "$@"



In theory, as no Modules’s module is loaded, I guess it should not has any influence, but I wouldn’t bet my life on this…

Have a nice day.


For the record. The environment-module had been installed when I‘d been asked by the support to install the xdebug module to troubleshot an issue some time ago… It is now uninstalled. I haven’t done all the tests I want to, but as one of my user used /bin/sh instead of /bin/bash I tested both to see if any difference. There is two options which differ then, notably “inherit_errexit”, which is true when in POSIX mode. I did not check yet, but I suspect Centreon to run the plugin scripts with errexit, which makes sens, and would explain while it is possible for a script to work when run from an interactive shell but not when the engine run it.