For some circumstances it would be nice to have multiple nrpe services started. This can easily be achieved by linking init-script (as known from net.lo) e.g. nrpe.management -> nrpe. Afterwards a config file nrpe.management.cfg in /etc/nagios could be used. Reproducible: Always
Created attachment 407580 [details, diff] patch to allow multiple nrpe-instances Patch attached allows multiple nrpe instances with linking init-scripts. The patch did not break any functionality, so it's just an enhancement.
Any news on this?
I would suggest opening a PR and mentioning mjo.
Marcel: sorry, this looks like a case of maintainership failure. None of the members of the "Sysadmin Bugs" have been touching this package in years. Michael (adding in CC) seems to be the de-facto maintainer because he's the only one who's been committing lately (or proxy-committing Tomas). If Michael isn't interested in taking over maintainership, maybe that this package would be better taken care of by you or Tomas as proxied maintainers?
This is/was already possible. OpenRC automatically sources /etc/conf.d/${RC_SVCNAME} in the init script, so if you symlink the init script to e.g. "nrpe.management", then you would want to override the config file name in /etc/conf.d/nrpe.management. The fact that your setting won't be clobbered is a little more obvious in the latest version of NRPE, but this: ${CFGFILE:=/etc/nagios/nrpe.cfg} will actually only set CFGFILE if it doesn't already exist -- meaning that you could set it in the conf.d file and have everything work like you wanted it to. The names of things have changed in newer versions of NRPE, so I'll be explicit. The init script for the latest version of NRPE has, command_args="--config=${NRPE_CFG} ${NRPE_OPTS}" and the value of NRPE_CFG comes from the associated conf.d file. By default, that's /etc/conf.d/nrpe, but if you symlink the init script to "nrpe.management", then in /etc/conf.d/nrpe.management you would put (for example), # The configuration file to use. NRPE_CFG="/etc/nagios/nrpe-management.cfg" When OpenRC starts your "nrpe.management" service, the value of NRPE_CFG will be obtained from that file (and not /etc/conf.d/nrpe), and everything will work like you want it to. @vdupras: thanks for noticing this... I don't really want to maintain NRPE because I don't use it, but here we are. The sysadmin project should probably drop this to maintainer-needed, or a better idea would be to convince Tomáš to become a developer =)
I'm afraid I have to slightly disagree. Yes, the config is read from conf.d/nrpe.<symlinkname>, where I can set CFGFILE to the path of my config file. But $command is still /usr/libexec/${SVCNAME}, which then will try to start an executable, which doesn't exist. So changing the init file like this would still be required: --- a/net-analyzer/nrpe/files/nrpe.init +++ b/net-analyzer/nrpe/files/nrpe.init @@ -13,7 +13,7 @@ get_config() { extra_started_commands="reload" -command=/usr/libexec/${SVCNAME} +command=/usr/libexec/${SVCNAME%%.*} command_args="-c ${CFGFILE} --daemon" pidfile=$(get_config pid_file) In my pull request [0] I also included a service file for non-OpenRC systems, to add the same functionality there. Does this make it worth to reopen the bug? [0] https://github.com/gentoo/gentoo/pull/9079
(In reply to Peter Große from comment #6) > > But $command is still /usr/libexec/${SVCNAME}, which then will try to start > an executable, which doesn't exist. You're right, but you're still looking at the old version of the init script. The modern version that comes with nrpe-3.2.1 is at, https://github.com/NagiosEnterprises/nrpe/blob/master/startup/openrc-init.in and the problem with the executable name has been fixed: command="@sbindir@/nrpe" > In my pull request [0] I also included a service file for non-OpenRC systems, to add the same functionality there. I think this is a good idea, but our newer versions of nrpe install the upstream systemd service file from, https://github.com/NagiosEnterprises/nrpe/blob/master/startup/default-service.in so your pull request should probably be directed there. Then it will automatically be included in the next version of nrpe.
Ah, yes, I was talking about the current stable nrpe version. The newer version is still masked as unstable, so I don't use that in a production environment. Okay, will file a bug upstream.
