After doing some research, it appears that <maxFileSize/> is a wonky setting WRT how well it's honored by logback. I let a GenerateFlowFile > LogAttribute flow run for a long time, and it just kept filling up. When I added <totalSizeCap/> that appeared to force expected behavior on total log size. We might want to add the following:
<cleanHistoryOnStart>true</cleanHistoryOnStart> <totalSizeCap>50GB</totalSizeCap> On Fri, Jul 7, 2023 at 11:33 AM Michael Moser <[email protected]> wrote: > Hi Mike, > > You aren't alone in experiencing this. I think logback uses a pattern > matcher on filename to discover files to delete. If "something" happens > which causes a gap in the date pattern, then the matcher will then fail to > pick up and delete files on the other side of that gap. > > Regards, > -- Mike M > > > On Thu, Jul 6, 2023 at 10:28 AM Mike Thomsen <[email protected]> > wrote: > >> We are using the stock configuration, and have noticed that we have a lot >> of nifi-app* logs that are well beyond the historic data cap of 30 days in >> logback.xml; some of those logs go back to April. We also have a bunch of 0 >> byte nifi-user logs and some of the other logs are 0 bytes as well. It >> looks like logback is rotating based on time, but isn't cleaning up. Is >> this expected behavior or a problem with the configuration? >> >> Thanks, >> >> Mike >> >
