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/cpid]/environ file, where epid] is the process ID of centengine. This will give you a list of the environment variables that centengine is using.

Hi,

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:

acentreon-engine@sr204032cti3700 ~]$ bash

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

LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=01;05;37;41:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.zst=01;31:*.tzst=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.wim=01;31:*.swm=01;31:*.dwm=01;31:*.esd=01;31:*.jpg=01;35:*.jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=01;36:*.au=01;36:*.flac=01;36:*.m4a=01;36:*.mid=01;36:*.midi=01;36:*.mka=01;36:*.mp3=01;36:*.mpc=01;36:*.ogg=01;36:*.ra=01;36:*.wav=01;36:*.oga=01;36:*.opus=01;36:*.spx=01;36:*.xspf=01;36:

MODULES_RUN_QUARANTINE=LD_LIBRARY_PATH LD_PRELOAD

LANG=en_US.UTF-8

HISTCONTROL=ignoredups

HOSTNAME=sr204032cti3700.hm.dm.ad

which_declare=declare -f

MODULES_CMD=/usr/share/Modules/libexec/modulecmd.tcl

USER=centreon-engine

PWD=/var/lib/centreon-engine

HOME=/var/lib/centreon-engine

LOADEDMODULES=

MAIL=/var/spool/mail/centreon-engine

SHELL=/bin/bash

TERM=xterm

TMOUT=3600

SHLVL=1

MANPATH=:

MODULEPATH=/etc/scl/modulefiles:/usr/share/Modules/modulefiles:/etc/modulefiles:/usr/share/modulefiles

LOGNAME=centreon-engine

MODULEPATH_modshare=/usr/share/Modules/modulefiles:2:/etc/modulefiles:2:/usr/share/modulefiles:2

PATH=/usr/share/Modules/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin

MODULESHOME=/usr/share/Modules

HISTSIZE=1000

LESSOPEN=||/usr/bin/lesspipe.sh %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 n "${MODULES_SILENT_SHELL_DEBUG:-0}" = '1' ]; then

 case "$-" in

 *v*x*)

 set +vx;

 _mlshdbg='vx'

 ;;

 *v*)

 set +v;

 _mlshdbg='v'

 ;;

 *x*)

 set +x;

 _mlshdbg='x'

 ;;

 *)

 _mlshdbg=''

 ;;

 esac;

 fi;

 unset _mlre _mlIFS;

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

 _mlIFS=$IFS;

 fi;

 IFS=' ';

 for _mlv in ${MODULES_RUN_QUARANTINE:-};

 do

 if D "${_mlv}" = "${_mlv##*
 if } -n "`eval 'echo ${'$_mlv'+x}'`" ]; then

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

 fi;

 _mlrv="MODULES_RUNENV_${_mlv}";

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

 fi;

 done;

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

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

 else

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

 fi;

 _mlstatus=$?;

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

 IFS=$_mlIFS;

 else

 unset IFS;

 fi;

 unset _mlre _mlv _mlrv _mlIFS;

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

 set -$_mlshdbg;

 fi;

 unset _mlshdbg;

 return $_mlstatus

}

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

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

 typeset swname='main';

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

 typeset swfound=0;

 unset MODULES_USE_COMPAT_VERSION;

 fi;

 else

 typeset swname='compatibility';

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

 typeset swfound=0;

 MODULES_USE_COMPAT_VERSION=1;

 export MODULES_USE_COMPAT_VERSION;

 fi;

 fi;

 if r $swfound -eq 0 ]; then

 echo "Switching to Modules $swname version";

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

 else

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

 return 1;

 fi

}

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

 eval "module $@";

 else

 /usr/bin/scl "$@";

 fi

}

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

}

_=/usr/bin/bash


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.