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

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.

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

Replies are listed 'Best First'.
Re^6: How to do a manual "logrotate" on a given file?
by JavaFan (Canon) on Nov 24, 2009 at 23:30 UTC
    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.
[reply]
      Thanks for explaining what 'rotating' means in that context.
      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.
      Isn't this a bit harsh? I posted a solution that I've used in the past and works for me, and cited its source (from a very knowledgeable and well-known Perl programmer). What else should I do? I honestly wasn't aware of the potential pitfalls, and I certainly wasn't "keeping information to myself" in a malicious way. My specific setup and usage are really not that arcane: a standard logfile that is accessed by a single process. The OP itself stated that his usage would be pretty much this one, so the solution actually helped.

      Are you suggesting that it would have been better to just not answer at all?

      Blog
[reply]

        Thank you both for your knowledge you shared, since the file is not locked at copy time (i Updated the Question) it is a rather simple copy task for me, but it is good to know i feel like it might have hit me sometime later ...

        Thanks in Advance
        MH
[reply]
        Are you suggesting that it would have been better to just not answer at all?
        If the choices are between an answer that 1) doesn't solve the OP's problem, 2) only works in very specific cases, and 3) is destructive otherwise on the one hand, and no answer on the other hand, I'd prefer no answer.
[reply]

In Section Seekers of Perl Wisdom