In the UserParameter specify an apparent pathname which is in fact
a dynamic link library and the name of a symbol contained in that library.
The api/contract expected of zbx_test_1 is the same as for zbx_execute
and can be implemented in less than 100 lines of code inside the file
This avoids the overhead of fork (or clone) and execve()
on /bin/sh, and whatever fork()execve() activity the sh command may need to do,
including reading/writing a state file if the implemenation of the variable
needs to preserve state across evaluations.
A patch file will be attached. It contains a diff for
and then some new files which are only needed to test and demonstrate
how the dynamic api could be used.
The big issue with this is that any serious bug in the user created
library, or in libraries called by that library, can cause the
zabbix_agentd to fail, possibly leading to false bug reports on the
A related feature
ZBXNEXT-701 which asks for there to be a persistent sub-agent