AEM always restarts due to "enable JMXRemote" step
Closed this issue · 8 comments
Debug: /Stage[main]/Aem_curator::Config_author_primary/Aem_curator::Reconfig_pre_aem[author: Execute Pre-reconfiguration for AEM]/Exec[author: Create /vagrant/sligro/files/author/certs]: 'mkdir -p /vagrant/sligro/files/author/certs' won't be executed because of failed check 'creates'
Notice: /Stage[main]/Aem_curator::Config_author_primary/Aem_curator::Reconfig_pre_aem[author: Execute Pre-reconfiguration for AEM]/File[change mode /vagrant/sligro/files/author/certs]/mode: mode changed '0755' to '0700'
Debug: /Stage[main]/Aem_curator::Config_author_primary/Aem_curator::Reconfig_pre_aem[author: Execute Pre-reconfiguration for AEM]/File[change mode /vagrant/sligro/files/author/certs]: The container Aem_curator::Reconfig_pre_aem[author: Execute Pre-reconfiguration for AEM] will propagate my refresh event
Notice: /Stage[main]/Aem_curator::Config_author_primary/Aem_curator::Reconfig_pre_aem[author: Execute Pre-reconfiguration for AEM]/File[/vagrant/sligro/files/author/start-env]/owner: owner changed 'vagrant' to 'aem-author'
Notice: /Stage[main]/Aem_curator::Config_author_primary/Aem_curator::Reconfig_pre_aem[author: Execute Pre-reconfiguration for AEM]/File[/vagrant/sligro/files/author/start-env]/group: group changed 'vagrant' to 'aem-author'
Debug: /Stage[main]/Aem_curator::Config_author_primary/Aem_curator::Reconfig_pre_aem[author: Execute Pre-reconfiguration for AEM]/File[/vagrant/sligro/files/author/start-env]: The container Aem_curator::Reconfig_pre_aem[author: Execute Pre-reconfiguration for AEM] will propagate my refresh event
Debug: /Stage[main]/Aem_curator::Config_author_primary/Aem_curator::Reconfig_pre_aem[author: Execute Pre-reconfiguration for AEM]/File[/vagrant/sligro/files/author/start-env]: The container Aem_curator::Reconfig_pre_aem[author: Execute Pre-reconfiguration for AEM] will propagate my refresh event
Notice: /Stage[main]/Aem_curator::Config_author_primary/Aem_curator::Reconfig_pre_aem[author: Execute Pre-reconfiguration for AEM]/File[/vagrant/sligro/files/author/start.orig]/owner: owner changed 'vagrant' to 'aem-author'
Notice: /Stage[main]/Aem_curator::Config_author_primary/Aem_curator::Reconfig_pre_aem[author: Execute Pre-reconfiguration for AEM]/File[/vagrant/sligro/files/author/start.orig]/group: group changed 'vagrant' to 'aem-author'
Debug: /Stage[main]/Aem_curator::Config_author_primary/Aem_curator::Reconfig_pre_aem[author: Execute Pre-reconfiguration for AEM]/File[/vagrant/sligro/files/author/start.orig]: The container Aem_curator::Reconfig_pre_aem[author: Execute Pre-reconfiguration for AEM] will propagate my refresh event
Debug: /Stage[main]/Aem_curator::Config_author_primary/Aem_curator::Reconfig_pre_aem[author: Execute Pre-reconfiguration for AEM]/File[/vagrant/sligro/files/author/start.orig]: The container Aem_curator::Reconfig_pre_aem[author: Execute Pre-reconfiguration for AEM] will propagate my refresh event
Notice: /Stage[main]/Aem_curator::Config_author_primary/Aem_curator::Reconfig_pre_aem[author: Execute Pre-reconfiguration for AEM]/File[/vagrant/sligro/files/author/start]/owner: owner changed 'vagrant' to 'aem-author'
Notice: /Stage[main]/Aem_curator::Config_author_primary/Aem_curator::Reconfig_pre_aem[author: Execute Pre-reconfiguration for AEM]/File[/vagrant/sligro/files/author/start]/group: group changed 'vagrant' to 'aem-author'
Debug: /Stage[main]/Aem_curator::Config_author_primary/Aem_curator::Reconfig_pre_aem[author: Execute Pre-reconfiguration for AEM]/File[/vagrant/sligro/files/author/start]: The container Aem_curator::Reconfig_pre_aem[author: Execute Pre-reconfiguration for AEM] will propagate my refresh event
Debug: /Stage[main]/Aem_curator::Config_author_primary/Aem_curator::Reconfig_pre_aem[author: Execute Pre-reconfiguration for AEM]/File[/vagrant/sligro/files/author/start]: The container Aem_curator::Reconfig_pre_aem[author: Execute Pre-reconfiguration for AEM] will propagate my refresh event
Debug: Aem_curator::Reconfig_pre_aem[author: Execute Pre-reconfiguration for AEM]: The container Class[Aem_curator::Config_author_primary] will propagate my refresh event
Info: Computing checksum on file /data/aem/author/crx-quickstart/bin/start-env
Debug: Evicting cache entry for environment 'production'
Debug: Deleted text domain :production: false
Debug: Caching environment 'production' (ttl = 0 sec)
Info: /Stage[main]/Aem_curator::Config_author_primary/File[/data/aem/author/crx-quickstart/bin/start-env]: Filebucketed /data/aem/author/crx-quickstart/bin/start-env to puppet with sum a385295a6cd081dfd4549c35961251cb
Debug: Evicting cache entry for environment 'production'
Debug: Deleted text domain :production: false
Debug: Caching environment 'production' (ttl = 0 sec)
Notice: /Stage[main]/Aem_curator::Config_author_primary/File[/data/aem/author/crx-quickstart/bin/start-env]/content: content changed '{md5}a385295a6cd081dfd4549c35961251cb' to '{md5}940ea5e7bae2fe4c9d0ccc844d5a2a6d'
Debug: /Stage[main]/Aem_curator::Config_author_primary/File[/data/aem/author/crx-quickstart/bin/start-env]: The container Class[Aem_curator::Config_author_primary] will propagate my refresh event
Notice: /Stage[main]/Aem_curator::Config_author_primary/File_line[author: enable JMXRemote]/ensure: created
Info: /Stage[main]/Aem_curator::Config_author_primary/File_line[author: enable JMXRemote]: Scheduling refresh of Service[aem-author]
Debug: /Stage[main]/Aem_curator::Config_author_primary/File_line[author: enable JMXRemote]: The container Class[Aem_curator::Config_author_primary] will propagate my refresh event
As you can see, the combination of the rewrite of the start-env script + enabling JMXRemote causes the AEM Service to be refreshed, therefore restarting AEM. This is not needed (no configuration was changed).
I believe an issue related to this was already addressed by @mbloch1986 in #151 , but there could be an additional item to fix here.
@henrykuijpers thanks for opening this issue. I tried to understand this and I think I did a mistake . As the reconfig_pre_aem manifest has the parameter aem_jvm_jmxremote_port but this Parameter actually does not get passed anywhere.
Therefore JMXRemote doesn't get activated or set in the start-env when the reconfiguration is enabled, if I'm not mistaken.
As a result this is the only time when the JMX Remote gets enabled or activated
which than notifies the aem service to restart.
So the behaviour is actually correct it's just a mistake that the reconfig_pre_aem manifest expects a parameter named aem_jvm_jmxremote_port.
I hope this helps and clarifies it's a little bit ?
It does clarify a little bit. However, I think the way that the start-env etc are rewritten, is not correct. There seem to be a few loose ends, that (due to changes in the files), cause AEM to restart where it's not necessary.
I'm not sure if it's only the JMX that has to do with this.
Can you validate this with a provisioned instance, then run the reconfig? And then run it again?
If the first reconfig doesn't actually change something, AEM doesn't have to restart, right? And the last reconfig (which for sure doesn't change anything) also shouldn't cause AEM to restart, right?
@henrykuijpers Thanks you're right I actually can reproduce it. My AEM sevice is getting refreshed as well. I'll do try to do a bit more debugging ...
Now this is very interesting ... these are the two events which are triggering a refresh of the AEM service which are:
2020-04-16 21:42:22 +1000 /Stage[main]/Aem_curator::Config_publish/File_line[publish: enable JMXRemote]/ensure (notice): created
2020-04-16 21:42:22 +1000 /Stage[main]/Aem_curator::Config_publish/File_line[publish: Add custom JVM OPTS settings]/ensure (notice): created
The reason why those two tasks are getting triggered in the first place is because we are resetting the file start-env during the reconfiguration process https://github.com/shinesolutions/puppet-aem-curator/blob/master/manifests/config_publish.pp#L138-L151 ... therfor the start-env has changed and the tasks Set JVM memory opts https://github.com/shinesolutions/puppet-aem-curator/blob/master/manifests/config_publish.pp#L179, enable JMXRemote https://github.com/shinesolutions/puppet-aem-curator/blob/master/manifests/config_publish.pp#L189 & Add custom JVM OPTS settings https://github.com/shinesolutions/puppet-aem-curator/blob/master/manifests/config_publish.pp#L189 will trigger a restart of the service ... I believe the only solution is to add another flag to enable/disable a reset of the binaries during the reconfiguration process.
@henrykuijpers The only possible solution I have here is to add a new enable flag. The default setting is == true so make sure you pass the new parameter with false. My tests so far were successfully which means the AEM Service wasn't restarted.
I'd like to dig a bit deeper and remove the whole customization with regards to start-env etc. I discussed with @cliffano about setting up a call to tackle this. I believe there should be no reason to do all this manually, this should be done with aem::config, but of course there's a reason this is not happening now?
For which use-case would you recommend aem::config exactly ?
My initial plan to manage the AEM binaries was using the aem::config module but because aem::config and our config manifests are creating the same directory crx-quickstart/install I decided against it due to the lack of testing. I would give it another try though.
@henrykuijpers We've updated the logic of setting the JVM options for the AEM start-env, with puppet-aem-curator version 3.12.0.
We are now resetting the file everytime the AEM Component config manifest runs. This should fix the issue that AEM always restarts when updating the start-env.
Let us know if you are still experiencing any issues. I'll close this issue until than.