Bug 1018293 - init.d script kills also any subsequent agents that were started
init.d script kills also any subsequent agents that were started
Status: CLOSED ERRATA
Product: Fedora EPEL
Classification: Fedora
Component: zabbix20 (Show other bugs)
el6
All Linux
unspecified Severity medium
: ---
: ---
Assigned To: Volker Fröhlich
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-11 11:53 EDT by Robin Roevens
Modified: 2014-01-09 20:09 EST (History)
2 users (show)

See Also:
Fixed In Version: zabbix-1.8.19-1.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-12-30 14:29:16 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description Robin Roevens 2013-10-11 11:53:58 EDT
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 12:43:20 EDT
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 13:17:24 EDT
That should be /etc/zabbix_agentd.conf. Thank you for your effort!
Comment 3 Volker Fröhlich 2013-12-13 04:40:54 EST
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 07:44:46 EST
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 17:43:20 EST
(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 09:15:41 EST
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 15:25:20 EST
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 12:50:19 EST
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 11:15:42 EST
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 14:29:16 EST
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 17:46:56 EST
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-09 20:09:28 EST
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.