Description of problem: "systemctl reload" command doesn't reload notifier configuration. It returns error. Version-Release number of selected component (if applicable): tendrl-notifier-1.5.4-2.el7rhgs.noarch How reproducible: 100% Steps to Reproduce: 1. get current date: $ date 2. get conf files for package : $ rpm -qc tendrl-notifier 3. reload configuration: $ systemctl reload tendrl-notifier step 3 returns error: Job for tendrl-notifier.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.
for step 3. see bug 1515276
Fixed: https://github.com/Tendrl/gluster-integration/issues/491
"systemctl reload" command doesn't reload notifier configuration. Checked with build: tendrl-notifier-1.5.4-3.el7rhgs.noarch tendrl-ui-1.5.4-4.el7rhgs.noarch tendrl-monitoring-integration-1.5.4-5.el7rhgs.noarch tendrl-grafana-selinux-1.5.3-2.el7rhgs.noarch tendrl-commons-1.5.4-4.el7rhgs.noarch tendrl-api-1.5.4-2.el7rhgs.noarch tendrl-api-httpd-1.5.4-2.el7rhgs.noarch tendrl-grafana-plugins-1.5.4-5.el7rhgs.noarch tendrl-ansible-1.5.4-1.el7rhgs.noarch tendrl-selinux-1.5.3-2.el7rhgs.noarch tendrl-node-agent-1.5.4-5.el7rhgs.noarch [root@dhcp37-59 ~]# systemctl status tendrl-notifier ● tendrl-notifier.service - Daemon to manage tendrl notifications Loaded: loaded (/usr/lib/systemd/system/tendrl-notifier.service; enabled; vendor preset: disabled) Active: inactive (dead) since Thu 2017-11-23 14:50:12 IST; 47min ago Process: 5601 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS) Main PID: 16911 (code=killed, signal=HUP) Nov 22 12:22:37 dhcp37-59.lab.eng.blr.redhat.com tendrl-notifier[16911]: Registering object namespace.tendrl.objects.Disk Nov 22 12:22:37 dhcp37-59.lab.eng.blr.redhat.com tendrl-notifier[16911]: Finding atoms in namespace.tendrl.objects.Disk.atoms Nov 22 12:22:37 dhcp37-59.lab.eng.blr.redhat.com tendrl-notifier[16911]: Finding flows in namespace.tendrl.objects.Disk.flows Nov 22 12:22:37 dhcp37-59.lab.eng.blr.redhat.com tendrl-notifier[16911]: Registering object namespace.tendrl.objects.Job Nov 22 12:22:37 dhcp37-59.lab.eng.blr.redhat.com tendrl-notifier[16911]: Finding atoms in namespace.tendrl.objects.Job.atoms Nov 22 12:22:37 dhcp37-59.lab.eng.blr.redhat.com tendrl-notifier[16911]: Finding flows in namespace.tendrl.objects.Job.flows Nov 22 12:22:37 dhcp37-59.lab.eng.blr.redhat.com tendrl-notifier[16911]: Registering object namespace.tendrl.objects.Memory Nov 22 12:22:37 dhcp37-59.lab.eng.blr.redhat.com tendrl-notifier[16911]: Finding atoms in namespace.tendrl.objects.Memory.atoms Nov 23 14:50:11 dhcp37-59.lab.eng.blr.redhat.com systemd[1]: Reloaded Daemon to manage tendrl notifications. Nov 23 14:50:12 dhcp37-59.lab.eng.blr.redhat.com tendrl-notifier[16911]: Findi
Fixed: https://github.com/Tendrl/notifier/issues/146
Giving pm_ack and including in 3.3.1.
"systemctl reload tendrl-notifier" reloads notifier configuration. ● tendrl-notifier.service - Daemon to manage tendrl notifications Loaded: loaded (/usr/lib/systemd/system/tendrl-notifier.service; enabled; vendor preset: disabled) Active: active (running) since Sat 2017-12-09 20:45:24 IST; 24h ago Process: 32228 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS) Main PID: 26942 (tendrl-notifier) CGroup: /system.slice/tendrl-notifier.service └─26942 /usr/bin/python /usr/bin/tendrl-notifier Dec 09 20:45:24 dhcp46-29.lab.eng.blr.redhat.com tendrl-notifier[26942]: Finding flows in namespace.tendrl.objects.DetectedCluster.flows Dec 09 20:45:24 dhcp46-29.lab.eng.blr.redhat.com tendrl-notifier[26942]: Registering object namespace.tendrl.objects.Disk Dec 09 20:45:24 dhcp46-29.lab.eng.blr.redhat.com tendrl-notifier[26942]: Finding atoms in namespace.tendrl.objects.Disk.atoms Dec 09 20:45:24 dhcp46-29.lab.eng.blr.redhat.com tendrl-notifier[26942]: Finding flows in namespace.tendrl.objects.Disk.flows Dec 09 20:45:24 dhcp46-29.lab.eng.blr.redhat.com tendrl-notifier[26942]: Registering object namespace.tendrl.objects.Job Dec 09 20:45:24 dhcp46-29.lab.eng.blr.redhat.com tendrl-notifier[26942]: Finding atoms in namespace.tendrl.objects.Job.atoms Dec 09 20:45:24 dhcp46-29.lab.eng.blr.redhat.com tendrl-notifier[26942]: Finding flows in namespace.tendrl.objects.Job.flows Dec 09 20:45:24 dhcp46-29.lab.eng.blr.redhat.com tendrl-notifier[26942]: Registering object namespace.tendrl.objects.Memory Dec 09 20:45:24 dhcp46-29.lab.eng.blr.redhat.com tendrl-notifier[26942]: Finding atoms in namespace.tendrl.objects.Memory.atoms Dec 10 21:29:13 dhcp46-29.lab.eng.blr.redhat.com systemd[1]: Reloaded Daemon to manage tendrl notifications. Tested with build : ------------------ tendrl-node-agent-1.5.4-15.el7rhgs.noarch tendrl-ansible-1.5.4-5.el7rhgs.noarch tendrl-selinux-1.5.4-1.el7rhgs.noarch tendrl-commons-1.5.4-8.el7rhgs.noarch tendrl-api-1.5.4-4.el7rhgs.noarch tendrl-ui-1.5.4-6.el7rhgs.noarch tendrl-grafana-plugins-1.5.4-14.el7rhgs.noarch tendrl-notifier-1.5.4-6.el7rhgs.noarch tendrl-grafana-selinux-1.5.4-1.el7rhgs.noarch tendrl-api-httpd-1.5.4-4.el7rhgs.noarch tendrl-monitoring-integration-1.5.4-14.el7rhgs.noarch There were some additional scenarios to be tested as required by Martin.
Scenario: 1. change some configuration variable in notifier configuration file 2. systemctl reload tendrl-notifier 3. check in output of "find /etc/tendrl/ -type f | xargs stat | grep '^Access: 2' " that notifier has read configuration 4. check logs that notifier used new value of configured option
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2017:3478