Description of problem: When these two files exist: /etc/foreman-proxy/settings.d/puppet_proxy_customrun.yml.rpmsave /etc/foreman-proxy/settings.d/puppet_proxy_puppetrun.yml.rpmsave Or when these two files exist: /etc/foreman-proxy/settings.d/puppet_proxy_customrun.yml /etc/foreman-proxy/settings.d/puppet_proxy_puppetrun.yml Satellite accumulates hundreds of errors like this each day, for each registered host: [W|app|39519d2e] Setting puppetrun has no definition, please define it before using Under these conditions, those errors can also be provoked by running this command on a host: # subscription-manager facts --update Note: The customer I worked with had a few hundred registered hosts, and over time more than one million such errors had accumulated on their system. Version-Release number of selected component (if applicable): customer server: satellite-6.10.2-1.el7sat.noarch foreman-2.5.2.18-3.el7sat.noarch puppetserver-6.15.3-1.el7sat.noarch puppet-agent-6.22.1-1.el7sat.x86_64 my reproducer: satellite-6.10.3-1.el7sat.noarch foreman-2.5.2.19-1.el7sat.noarch puppetserver-6.15.3-1.el7sat.noarch puppet-agent-6.22.1-1.el7sat.x86_64 How reproducible: 100% Steps to Reproduce: 1. install the puppet_proxy files in /etc/foreman-proxy/ 2. run "satellite-installer" 3. reboot 4. run "subscription-manager facts --update" on a host Actual results: I see this in /var/log/foreman/production.log: [W|app|39519d2e] Setting puppetrun has no definition, please define it before using Expected results: No error message. Additional info: I was able to reverse this issue on my reproducer by following these steps: 1. move the puppet_proxy files in /etc/foreman-proxy/ to another location 2. run "satellite-installer" 3. reboot
Follow-up: After further testing, I've found that my workaround (mentioned in the problem description, and also below) is not, in fact, a reliable fix: 1. move the puppet_proxy files in /etc/foreman-proxy/ to another location 2. run "satellite-installer" 3. reboot
I have been able to reproduce this issue easily just by registering my content host to a Satellite 6.10 server. I've done a little investigating, and I see the error is thrown from this file, from the SettingRegistry class: ~~~ /usr/share/foreman/app/services/setting_registry.rb ~~~ We see the definition is getting assigned here, by seeing if the name "puppetrun" exists in the settings table from the foreman db: ~~~ 16 def find(name) 17 logger.warn("Setting is not initialized yet, requested value for #{name} will be always nil") unless ready? 18 @settings[name.to_s] 19 end ~~~ I can see that Satellite 6.8 does have the puppetrun entry in the foreman settings table, but 6.9 and 6.10 do not. Only Satellite 6.10 throws this error, while Satellite 6.9 does not. Further, I think this wasn't caught until the SettingRegistry class was introduced, which appears to have been added in Satellite 6.10. Since seeing this bug, I have seen this issue appear in multiple customer environments (usually heavily logged since each host is triggering this). I'm not exactly sure where the value of puppetrun is getting introduced (i.e. the rhsm libraries from the content host, or somewhere still from the Satellite server). Is there any way we can disable this feature, to prevent all of these WARN logging messages? Kind regards,
Puppetrun was removed from 6.9 and later versions (see https://bugzilla.redhat.com/show_bug.cgi?id=1905096), so there shouldn't be any way how to disable something what should be missing. Strange that this bug manifests in 6.10 and not in 6.9.
This seems to no longer be occurring with 6.10.
After thorough testing and analysis on Satellite 6.13, I regret to inform you that I was unable to reproduce the issue as described in the ticket. Despite following the provided steps, the issue could not be replicated. As a result, I am closing the BZ ticket. However, please note that if the issue reoccurs or if additional information becomes available, we can reopen the ticket for further investigation.