a test to know if an external script is started from Zabbix.

[frater]

When an external script is run from Zabbix it will send 1 parameter extra.
This is fine if you know this.
I want to use such a script also from the console and want it to act the same.

I'm now using this code to identify zabbix:

echo "${BASH_SOURCE}" | grep -q "zabbix" && shift 1

I did some tests to see which 'env' or 'set' variable I could use and I was surprised to see that these scripts are run as root and not as 'zabbix'.
At least the variable 'USER' was set to 'root'.

Can't Zabbix add an extra environment variable which I can use to make such a test more reliable?

[richlv]

given that zabbix daemons run as zabbix user by default, it's a bit doubtful they would be even able to spawn processes under root...

as for this specific case, why not keep your scripts as-is and use a wrapper script when launching them from zabbix ?

[frater]

I Was surprised I couldn't check the environment variable 'USER' which I expected to be 'zabbix'. Why isn't it set properly?

[richlv]

zabbix does the minimum required to launch the command - it does not set up the environment for you, does not include profile etc

[frater]

I'm not complaining....
I'm merely doing a request to make it easier for me to determine how the script was called.
I wouldn't need it in the first place if the parameters were passed normally.

Zabbix 2.0 is the future and I don't think external scripts are used that often, so I can just write my scripts for >1.96 only.
No need to do 'shift 1' for >1.96, so this is good. The scripts therefore only need special handling for Zabbix <1.9
I can 'comment out' that part with the remark to uncomment it if you're using the 'old zabbix'

It would help if you can do it....

I added this line to one of my scripts to see the environment.....

env >>/tmp/zabbix

This is how it looks in 1.96. I did the same in 1.86 and I believe the variable 'USER' was set to 'root', but I'm not 100% sure.

# tail -f /tmp/zabbix

PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/sbin:/sbin:/usr/local/sbin:/sbin:/usr/sbin:/bin:/usr/bin
RUNLEVEL=2
runlevel=2
PWD=/
VERBOSE=no
previous=N
PREVLEVEL=N
SHLVL=1
HOME=/
_=/usr/bin/env
CONSOLE=/var/log/init.fifo
SHELL=/bin/sh
TERM=linux
INIT_VERSION=sysvinit-2.88

[frater]

BTW.. There's another change that's not documented.

On Zabbix 1.8x I was able to pass multiple parameters separated with a space.

In Zabbix 1.8x these were sent unquoted so I could do

Item:

extscript[ {HOST.CONN}, PAR1 PAR2 ]

echo "${BASH_SOURCE}" | grep -q "zabbix" && shift 1
PAR1="$1"
PAR2="$2"

In Zabbix >1.9 both parameters are given to $1 (because they are sent quoted)

I worked around that by using this code which works in both 1.8x and >1.9

echo "${BASH_SOURCE}" | grep -q "zabbix" && shift 1
PAR1=`echo "$*" | awk '{print $1}'
PAR1=`echo "$*" | awk '{print $2}'

Maybe I should just forget about writing scripts that work on CLI, 1.8x and >1.9 and separate the parameters with a comma, just like its done for the agent. I then don't need to write any code to differentiate between CLI and Zabbix....

[richlv]

BTW.. There's another change that's not documented.

On Zabbix 1.8x I was able to pass multiple parameters separated with a space.

i'd object to that

http://www.zabbix.com/documentation/.../upgrade_notes

"External check parameter handling was changed. Previously, only one parameter was accepted. Starting with Zabbix 2.0, key syntax conforms to other types of items and multiple comma-separated parameters may be passed."