Question

Here is the deal:
I have a multiple process system (pre-fork model, similar to apache). all processes are writing to the same log file (in fact a binary log file recording requests and responses, but no matter).

I protect against concurrent access to the log via a shared memory lock, and when the file reach a certain size the process that notices it first roll the logs by:

1. closing the file.
2. renaming log.bin -> log.bin.1, log.bin.1 -> log.bin.2 and so on.
3. deleting logs that are beyond the max allowed number of logs. (say, log.bin.10)
4. opening a new log.bin file

The problem is that other processes are unaware, and are in fact continue to write to the old log file (which was renamed to log.bin.1).

I can think of several solutions:

1. some sort of rpc to notify other processes to reopen the log (maybe even a singal). I don’t particularly like it.
2. have processes check the file length via the opened file stream, and somehow detect that the file was renamed under them and reopen log.bin file.

None of those is very elegant in my opinion.

thoughts? recommendations?

Answer 1

Your solution seems fine, but you should store an integer with inode of current logging file in shared memory (see stat(2) with stat.st_ino member).

This way, all process kept a local variable with the opened inode file.

The shared var must be updated when rotating by only one process, and all other process are aware by checking a difference between the local inode and the shared inode. It should induce a reopening.