be able to configure appender.log_file.policies.cron.evaluateOnStartup from the ansible role

[choogendoornsh]

SUMMARY

We want to be able to configure appender.log_file.policies.cron.evaluateOnStartup using the ansible role

Reason:
The /etc/systemd/system/amq-broker.service service currently has the following logic to check for the uptime status of the broker when restarted.

ExecStartPost=/usr/bin/timeout 180 sh -c 'tail -n 15 -f /opt/amq/amq-broker/log/artemis.log | 
sed "/AMQ221109\\\\|AMQ221001\\\\|AMQ221034/ q" && /bin/sleep 10'

We have the following settings in our log4j.properties:
_appender.log_file.policies.cron.schedule = 0 0 0 * * ? #new rollover file every midnight
appender.log_file.filePattern = ${sys:artemis.instance}/log/artemis.log.%d{yyyy-MM-dd}.%i
appender.log_file.policies.cron.evaluateOnStartup = true_

However, we experience that in combination with these properties the first deployment (systemctl restart amq-broker) (of the day) always fails with a timout after 180 seconds. If we check the artemis.log files right after, we see that (one of) the correct AMQ codes actually DID get logged in the first 20 seconds. After testing we discovered that right after the first systemctl restart amq-broker , during the "tail" in the above amq-broker.service-command, the cronjob creates an artemis.log.2024-11-30.1 file, and somehow in this process the "tail" loses track of the artemis.log file. This is speculating but maybe the log4j logic in the jvm renames the artemis.log file and the tail in the service just follows "tailing" the renamed fail (now called artemis.log.2024-11-30.1) which will not be updated anymore since the codes that the tail is waiting for will appear in the newly created artemis.log

If we run systemctl restart amq-broker right after the first (failed) restart, this always is succesfull within 15 seconds max.

We have noticed that setting the appender.log_file.policies.cron.evaluateOnStartup = false in log4j2.properties (the default is true) solves this issue, and the broker always starts nicely since no rollover file is created during the restart. This parameter is however not configurable via ansible as of yet.

So a solution would be for us to be able to configure the appender.log_file.policies.cron.evaluateOnStartup = false via the Ansible role. (for artemis as well as for audit.log)

Thank you!

edit: actually we just discovered that changing tail -n 15 -f to tail -n 15 -F (capital F) will also to the trick, because with an -F appearantly log4j will continue to tail on the filename "audit.log" it was originally following, even it that was renamed during the tail.

ISSUE TYPE

• Feature Idea