After Log Rolling, Pervious, Uncompressed Log File is Deleted But _Not_ Closed and its Disk Space Not Freed

This issue is archived. You can view it, but you can't modify it. Learn more

XMLWordPrintable

    • Type: Bug
    • Resolution: Duplicate
    • Priority: Critical
    • Component/s: core
    • Environment:
      Linux, CentOS 5.5, kernel 2.6.18-194.el5; x86_64; Java 1.6.0_10-b33

      When Jenkins performs log-rolling, it compresses the completed log file leaving a date-stamped, ".gz"-suffixed equivalent while moving on to a new "jenkins.log" file. It also unlinks the old plain-text (non-compressed) log file. However, it does not close its descriptor to that log file and thus its disk space is not freed until Jenkins itself is restarted.

      On a Linux system, such ghost files can be discovered via entries in /proc/NNN/fd/*:

      1. ll /proc/[0-9][0-9]/fd |egrep '/var.(deleted)'

            Assignee:
            Andrew Bayer
            Reporter:
            Randall Schulz
            Archiver:
            Jenkins Service Account

              Created:
              Updated:
              Resolved:
              Archived: