RotatingFileHandler fails when logs are stored in a non-posix file system docker-mounted in Linux-OS about cpython

[serhiy-storchaka]

This is strange. There were no changes in this part of code since 3.11 (and the last change was making so that only regular files are now rotated, not symlinks, devices or named pipes). The EBADF error should only be raised if the file descriptor was closed, unless there is a nonstandard behavior for your “double mounting” combination. This can only happen when the RotatingFileHandler is concurrently used in different threads. But every code that uses self.stream should be guarded by a special per-handler lock, so I don't know how this is practically possible.

cc @vsajip

[lollo0296]

This is strange. There were no changes in this part of code since 3.11

I took my time to look at the ohter projects of us. I found out that we never actually deployed 3.11 to production. We have one project running on 3.9 and the rest are rocking 3.10.
So, as far as we know, the bug might have been introduced with the changes in 3.11.

Strange fact 😵: My app runs 24/7. It runs the whole week no problem, writes a lot of log entries like a charme. But when I come back after the weekend, I find it “stuck” on this error. As if the shouldRollover() method somehow gets called at specific interval or day-of-week? I observed this behavior 3 weeks in a row. Could it be?

@serhiy-storchaka do you have a possible explanation for this?

[serhiy-storchaka]

Do you use RotatingFileHandler or TimedRotatingFileHandler? The former should not rely on time. Can it be an external issue, caused by scheduled maintenance of the mounted file system? How much rollovers occurred in a week?

BTW, do your program use forking? If the handler is created in the parent process which was later forked, the file descriptors may be closed in the child process. Although nothing was changed in 3.10 or 3.11. Significant changes were in 3.4.

Try to unmount the file system with logs and then mount it back. Does it cause the same issue?