Bug 1018293 - init.d script kills also any subsequent agents that were started
Summary: init.d script kills also any subsequent agents that were started
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: zabbix20
Version: el6
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Volker Fröhlich
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-10-11 15:53 UTC by Robin Roevens
Modified: 2014-01-10 01:09 UTC (History)
2 users (show)

Fixed In Version: zabbix-1.8.19-1.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-12-30 19:29:16 UTC


Attachments (Terms of Use)
Generic initrd script for zabbix agent (1.19 KB, patch)
2013-10-11 16:43 UTC, Robin Roevens
no flags Details | Diff

Description Robin Roevens 2013-10-11 15:53:58 UTC
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.

Comment 1 Robin Roevens 2013-10-11 16:43:20 UTC
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.

Comment 2 Volker Fröhlich 2013-10-11 17:17:24 UTC
That should be /etc/zabbix_agentd.conf. Thank you for your effort!

Comment 3 Volker Fröhlich 2013-12-13 09:40:54 UTC
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.

Comment 4 Robin Roevens 2013-12-13 12:44:46 UTC
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 ? :-)

Comment 5 Volker Fröhlich 2013-12-13 22:43:20 UTC
(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

Comment 6 Fedora Update System 2013-12-15 14:15:41 UTC
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

Comment 7 Fedora Update System 2013-12-15 20:25:20 UTC
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).

Comment 8 Fedora Update System 2013-12-20 17:50:19 UTC
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

Comment 9 Fedora Update System 2013-12-25 16:15:42 UTC
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

Comment 10 Fedora Update System 2013-12-30 19:29:16 UTC
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.

Comment 11 Fedora Update System 2014-01-04 22:46:56 UTC
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.

Comment 12 Fedora Update System 2014-01-10 01:09:28 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.