0

Technical details:

Docker versions: This has happened on docker 18, 19 and 20, at several minor versions.

19.03.12 and 20.10.3 are the most recent installs I've got running.

OS: Ubuntu 16.04/18.04/20.04, all display this behavior.

All installs use overlay2.

Description:

Running lsof | grep -i 'deleted reveals log files being held on to, from processes running inside docker containers. Grepping the PID in the output of ps -aef --forest reveals the processes are running inside a docker container.

Running the same process outside docker has thus far not reproduced this behavior.

This started to become apparent when tens of gigabytes of diskspace could not be found.

This happens both for java and nodejs processes, using logback/winston respectively.

These logger libraries take care of their own logrotating and are not being tracked by a distinct logrotate service.

I have no clue what causes this behavior, and why it doesn't happen when not dockerized.

Googling "docker logrotate files being held" just gives results on logrotating the log files of docker itself.

I'm not finding what I'm looking for with general searching, so I came here, to ask if maybe someone recognizes this and it's actually an easy fix? Some simple thing I forgot but has to be pointed out?

Here's hoping someone knows what's going on.

larsks
  • 277,717
  • 41
  • 399
  • 399
KoenDG
  • 107
  • 8
  • It's not clear why you're including `logrotate` in your question title or google searches, since if I'm reading this correctly you're talking about applications that implement their own log rotation rather than using the `logrotate` package. – larsks Sep 09 '21 at 16:21
  • @larsks It's the concept, isn't it? Yes, they're not using the `logrotate` package... but the act they are performing is a logrotate. Don't really know how to split that up in a short sentence. – KoenDG Sep 10 '21 at 14:24

0 Answers0