Closed raghuvennam closed 5 years ago
To be sure that future logback.xml changes are available can this be just done inside the Dockerfile with a simple sed
RUN sed -i -e 's|<maxHistory>90</maxHistory>|<maxHistory>30</maxHistory>|g' ${NEXUS_HOME}/etc/logback/logback*.xml
Are you referring to java.lang.NullPointerException
and you think this is caused by the missing logback file?
Yes. Its due to missing 'tasklogfile' appender exists in logback.xml
I am actually not so sure it is related. Do you have any info/blog post that connect the nullExpection to the logback?
I did the same change and the image was built and working with Cleanup service (Admin - Cleanup repositories using their associated policies)
If you look closely at the error messages
019-07-26 09:51:36,575+0000 ERROR [quartz-3-thread-6] SYSTEM org.sonatype.nexus.logging.task.TaskLogHome - Could not find a Logback SiftingAppender named 'tasklogfile' in the logback configuration. Please check that the 'tasklogfile' appender exists in logback.xml 2019-07-26 09:51:36,575+0000 INFO [quartz-3-thread-6] SYSTEM org.sonatype.nexus.cleanup.internal.task.CleanupTask - Starting cleanup 2019-07-26 09:51:36,623+0000 ERROR [quartz-3-thread-6] *SYSTEM org.sonatype.nexus.cleanup.internal.task.CleanupTask - Failed to run task 'Run repository cleanup' java.lang.NullPointerException: null
The task fails to run due to missing appender in the logback.xml
Do you see any issue updating the logback.xml to be in line with the actual nexus codebase?
Is your problem with the cleanup is with the default cleanup task? If so, we are running Nexus version 3.17.0 , we get the same log of ERROR [quartz-3-thread-6] *SYSTEM org.sonatype.nexus.logging.task.TaskLogHome - Could not find a Logback SiftingAppender named 'tasklogfile' in the logback configuration. Please check that the 'tasklogfile' appender exists in logback.xml` but we don't get NullException and the cleanup task runs successfully. That's why I am not sure at all that the exception you see in your log is related to the Logback file. Also, according to the comments on the code you referenced. NExus is forgiving to the fact that sifftingAppender is missing and will not fail the start of the application.
we have never seen the cleanup job succeed in our setup which is base helm install.
Let's take an example, we have code that uses 10 Appenders and those appenders are added into GitHub in logback.xml. When you create the docker image you overwrite it with logback.xml containing only 5 (imaginary number) appenders. This is the problem.
Either case aligning the logback.xml to the upstream should not be a major concern right?
I created a PR to align logback.xml
: https://github.com/travelaudience/docker-nexus/pull/24
Unfortunately, I am still not sure how sed
(as you suggested above) will help with getting upstream updates for logback.xml
or keeping your additional custom appenders, can you please clarify that?
Do you mean to add
RUN sed -i -e 's|<maxHistory>90</maxHistory>|<maxHistory>30</maxHistory>|g' ${NEXUS_HOME}/etc/logback/logback*.xml
instead of
COPY logback.xml ${NEXUS_HOME}/etc/logback/logback.xml
?
or before/after?
Currently, I don't have time to try and test it and see what you mean so it wlll be easier if you could explain with a PR.
I see that the logback.xml is updated with the latest content. Instead of replacing the file if the reason behind copying the file is to just change the maxHistory value from 90 days to 30 days. It's just a replacement of the dockerfile. I will raise a PR with the changes soon.
The default logback.xml https://github.com/sonatype/nexus-public/blob/master/assemblies/nexus-base-template/src/main/resources/overlay/etc/logback/logback.xml has additional loggers.
These tasklogfile logger block are needed for the Admin clean up tasks added as part of release 3.14.0