Actually, for controlling the zabbix server at run-time, zabbix use a signal subsystem that is linux specific (for example you can't control zabbix at runtime on other operating systems).
Being zabbix also used outside of Linux (and I know a lot of cases for it), the proposal is to replace the signal-based control mechanism with a socket-based one. This will allow:

• Safety, as signal handlers interrupt the normal flow of the program (in particular, zabbix is not completely safe on the syscall handling for this).
• Flexibility: It will be possible to implement in a future complex controlling behaviors (like statistics on stdout regarding the server performances).
• Portability: All the systems where zabbix compile support the standard sockets interfaces.

My idea is to have a separated utility (named like "zabbixctl"), that take care of the communication with the server and whatnot and report to the user if required (numbers, if the operation was successful etc).