Hide Forgot
Description of problem: When multiple zabbix agent instances are started on one host, all will get killed by the init.d script of one such an instance when stop or restart is used. Version-Release number of selected component (if applicable): all How reproducible: Start 2 or more instances of Zabbix agents. Then stop or restart one of the instances with the provided init.d script. Steps to Reproduce: 1.Create new /etc/zabbix/zabbix_agentd.conf file for every required agent instance (changing PidFile, ListenPort and HostName) (example /etc/zabbix/zabbix_agentd_inst2.conf) 2.Copy /etc/init.d/zabbix-agent for every required agent (example: cp /etc/init.d/zabbix-agent /etc/init.d/zabbix-agent-inst2) 3.Edit the copied init.d scripts to use the correct config file (by adding -c <path_to_config> to a new $param variable which is added at the end of the daemon line in the start routine) and change syscf and lockfile variables to represent this agent instance 4. Start the new instance(s) with the new init scripts 5. /etc/init.d/zabbix-agent stop or /etc/init.d/zabbix-agent restart Actual results: All zabbix agents are stopped (and in case of restart only one is restarted, the rest remains stopped) Expected results: Only the zabbix agent instance for which this particular init script is, should stop. Other instances should be left untouched Additional info: Suggested fix: - add a variable pidfile containing the pidfile-location as configured in the zabbix_agentd.conf file (could be automated to make the init-script even copy friendlier) - call killproc with parameter -p $pidfile in the the stop routine to prevent killing other instances of the agent.
Created attachment 811278 [details] Generic initrd script for zabbix agent Added a patch containing the changes I made to the zabbix initrd script so it can be easily copied for a new zabbix agent instance with minimal editing. (Just have to edit the chkconfig and INIT INFO) By default it assumes the config file to be in /etc/zabbix/zabbix_agentd.conf. Any subsequent instances will need a /etc/sysconfig file with the same name as the init script defining the variable CFG_FILE containing the full path of this instance its config file.
That should be /etc/zabbix_agentd.conf. Thank you for your effort!
Robin, I'm not completely happy with the information your patch would echo. The Hostname setting is only mandatory for active agents. If Hostname is not defined, you are echoing the output of the hostname command. The problem is, that has nothing to do with Zabbix at all. Furthermore you can use a HostnameItem instead of Hostname. While the example for this is set to system.hostname in the agentd file, this information is not suited to distingush between different instances of the agent running. With no better solution in mind, I'd rather leave the echo as it was or define a variable to be sourced from /etc/sysconfig.
Hostname is indeed not mandatory, as HostnameItem is used to set Hostname if that is not set. By default, for single agent instances, I personally don't use Hostname nor HostnameItem, even for Active agents thus defaulting to HostnameItem=system.hostname, which comes down to Hostname= the output of the hostname command (so in this case it actually does have something to do with Zabbix). HostnameItem is overridden by Hostname, hence my logic in the init script. In case of multiple zabbix agents on one host, you will need a unique Hostname (or HostnameItem to something generating a unique id for each instance) set in all but one instance, otherwise I don't really see the purpose of running multiple instances. However you have a point about HostnameItem. If Hostname is not set and HostnameItem is set to something else than system.hostname, then my patch disregards that and uses the output of hostname, which in this case indeed has nothing to do with zabbix. To actually get the result of the HostnameItem-item is indeed tricky.. When set to system.run[], it could be emulated by extracting what to run and actually run it to retrieve it's output.. But for other possible items I think it is a bit over the top to try to emulate the agent to get the resulting output. And I don't think there is another way to get the output of an item without the agent already running.. ? On the other hand, I think most of the use cases are already covered in the current behaviour, additionally the system.run[] item could be emulated and when another HostnameItem is used, it could echo 'custom HostnameItem' or so. And on top of that all this behaviour could be overriden by a custom /etc/sysconfig variable. What do you think after reading my though flow ? :-)
(In reply to Robin Roevens from comment #4) > Hostname is indeed not mandatory, as HostnameItem is used to set Hostname if > that is not set. > By default, for single agent instances, I personally don't use Hostname nor > HostnameItem, even for Active agents thus defaulting to > HostnameItem=system.hostname, which comes down to Hostname= the output of > the hostname command (so in this case it actually does have something to do > with Zabbix). > HostnameItem is overridden by Hostname, hence my logic in the init script. > > In case of multiple zabbix agents on one host, you will need a unique > Hostname (or HostnameItem to something generating a unique id for each > instance) set in all but one instance, otherwise I don't really see the > purpose of running multiple instances. You could use different agents and different servers. In that case, having the same name is valid. Furthermore, if the agent is only used passively, the name setting is completely meaningless. > However you have a point about HostnameItem. If Hostname is not set and > HostnameItem is set to something else than system.hostname, then my patch > disregards that and uses the output of hostname, which in this case indeed > has nothing to do with zabbix. > To actually get the result of the HostnameItem-item is indeed tricky.. > When set to system.run[], it could be emulated by extracting what to run and > actually run it to retrieve it's output.. But for other possible items I > think it is a bit over the top to try to emulate the agent to get the > resulting output. And I don't think there is another way to get the output > of an item without the agent already running.. ? You could use zabbix_agentd -t to evaluate items, but no warranty. > > On the other hand, I think most of the use cases are already covered in the > current behaviour, additionally the system.run[] item could be emulated and > when another HostnameItem is used, it could echo 'custom HostnameItem' or > so. And on top of that all this behaviour could be overriden by a custom > /etc/sysconfig variable. > > What do you think after reading my though flow ? :-) Thanks a lot for all the details! I think that's all terribly complex and I therefore just solved the original problem. :) On top of that, I did the same for proxy and server, and gave the init scripts a general overhaul. I'd be really happy if you would review and test my changes: http://pkgs.fedoraproject.org/cgit/zabbix20.git/commit/?h=el6&id=3e7c729db2fc5f92e565690b6ebd1f2b5f6191b3
zabbix20-2.0.10-2.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/zabbix20-2.0.10-2.el6
Package zabbix20-2.0.10-2.el6: * should fix your issue, * was pushed to the Fedora EPEL 6 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=epel-testing zabbix20-2.0.10-2.el6' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12384/zabbix20-2.0.10-2.el6 then log in and leave karma (feedback).
zabbix20-2.0.10-2.el5 has been submitted as an update for Fedora EPEL 5. https://admin.fedoraproject.org/updates/zabbix20-2.0.10-2.el5
zabbix-1.8.19-1.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/zabbix-1.8.19-1.el6
zabbix20-2.0.10-2.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.
zabbix20-2.0.10-2.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report.
zabbix-1.8.19-1.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.