D4Science Infrastructure

I guess this problem is present in all the containers gCore based.
I've checked the following nodes and this issue is present in all the following nodes:

node66.p.d4science
node24.p.d4science
collector-pre
registry-pre

The configuration is the following so we should have only 30 access.log files in the container:

#GCUBEHandler logger 
log4j.logger.org.gcube.common.handlers=TRACE,ACCESS
log4j.appender.ACCESS=org.apache.log4j.DailyRollingFileAppender
log4j.appender.ACCESS.file=${GLOBUS_LOCATION}/logs/access.log
log4j.appender.ACCESS.DatePattern='.'yyyy-MM-dd
log4j.appender.ACCESS.layout=org.apache.log4j.PatternLayout
log4j.appender.ACCESS.layout.ConversionPattern=%d{ISO8601} %-5p %c{2} [%t,%M:%L] %m%n
log4j.appender.ACCESS.threshold=INFO
log4j.appender.ACCESS.MaxBackupIndex=30
log4j.appender.ACCESS.MaxFileSize=10000KB

I'm going to investigate on this

The property MaxBackupIndex is present on the appender but it doesn't take effect because the current version of Log4j (Apache log4j 1.2.6) does not provide any mechanism to delete old log files if you are using DailyRollingFileAppender.
So I guess we can provide a fast solution installing a cronjob to do this job and deploy it on every gCore based node. What do you think about it?

In the attachment, there should be the servers running gCore. It is a small number of servers that should be dismissed in the first semester of 2018. I would implement the shortest and costless solution for those servers.