Red Hat Bugzilla – Bug 1515268
monitoring - doesn't reload configuration
Last modified: 2018-08-14 07:15:41 EDT
Description of problem: "systemctl reload" command doesn't reload monitoring configuration. It returns error. Version-Release number of selected component (if applicable): tendrl-monitoring-integration-1.5.4-4.el7rhgs.noarch How reproducible: 100% Steps to Reproduce: 1. get current date: $ date 2. get conf files for package: $ rpm -qc tendrl-monitoring-integration 3. reload configuration: $ systemctl reload tendrl-monitoring-integration step 3 returns error: Job for tendrl-monitoring-integration.service invalid. it it pass then we can continue to step 4. 4. check if conf files from 2. are touched: $ find /etc/tendrl/ -type f | xargs stat | egrep '^Access: 2|File:' Actual results: "systemctl reload" doesn't reload service configuration and returns error. Expected results: "systemctl reload" reloads service configuration. Additional info: Cite from systemd documentation: reload PATTERN... Asks all units listed on the command line to reload their configuration. Note that this will reload the service-specific configuration, not the unit configuration file of systemd. If you want systemd to reload the configuration file of a unit, use the daemon-reload command. In other words: for the example case of Apache, this will reload Apache's httpd.conf in the web server, not the apache.service systemd unit file. This command should not be confused with the daemon-reload command.
Fixed: https://github.com/Tendrl/gluster-integration/issues/491
Tested with: tendrl-monitoring-integration-1.5.4-8.el7rhgs.noarch There's no error when reload is made. However changes in configuration files are not reloaded. Access time on those configuration files is not changed and just to be sure I changed some settings (e.g. etcd port) without any change in behaviour of the service.
Tested with: tendrl-monitoring-integration-1.5.4-11.el7rhgs.noarch When I tried change configuration first time there was an error in log, however the service is still running, which should not. It should behave similarly like when it is run with the bad configuration (goes to failed state and stop). Moreover when I tried that again there was no error in log just line with this sentence 'Reloaded Monitoring Integration'.
Moving the bug out of 3.3.z