in reply to Re^2: How to do a manual "logrotate" on a given file?
in thread How to do a manual "logrotate" on a given file?

I don't know much about concurrent access to files, but wouldn't locking the file solve this issue?

  • Comment on Re^3: How to do a manual "logrotate" on a given file?

Replies are listed 'Best First'.
Re^4: How to do a manual "logrotate" on a given file?
by JavaFan (Canon) on Nov 24, 2009 at 19:38 UTC
    Well, you would have to lock the file using the flock call of Tie::File. It will invalidate the cache, so it's not efficient. And then it will only work if the writers use flock as well (which not every writer actually needs to do; if all writers open the file for append, and writes are smaller than the buffer size (typically 8k), data won't be garbled).

    But I fail to see the point of Tie::File in the first place. Considering the OP just wants to move files, and doesn't express any wish to actually remove data, what's the point of reading in the file in the first place?

      Maybe I misunderstood what the OP needed, or the meaning of "rotate a logfile". Another thing that hinted me towards thinking that the solution I posted might be what he needed was when he said "I could store a week (of logs) till overwriting the first log (entry)". In parenthesis I added words that illustrate my interpretation of the problem.

      Regarding the locking / efficiency issues, I don't have much to comment since I don't work in an environment that has me concerned about them. Personally though, I would wait until those issues arose before discarding any correct solution.

        With "rotating a logfile" is commonly understood that after a certain period, or reaching a certain size, logfiles are moved, compressed, and/or thrown away. A not uncommon setup is to rotate a logfile every day, keep logfiles for a week, and compress the all of them except the current one, and they one of yesterday. Once a day, the following happens:
        1. rm logfile.6.gz
        2. mv logfile.5.gz logfile.6.gz
        3. mv logfile.4.gz logfile.5.gz
        4. mv logfile.3.gz logfile.4.gz
        5. mv logfile.2.gz logfile.3.gz
        6. mv logfile.1.gz logfile.2.gz
        7. mv logfile.0 logfile.1
        8. gzip -9 logfile.1
        9. mv logfile logfile.0
        Personally though, I would wait until those issues arose before discarding any correct solution.
        That's all fine, but I don't think it's fine to suggest such a strategy to someone seeking answer, without giving any indication that it may not work at all, and just keeping it for yourself that what you suggest only works in your specific setup.