• Type: Improvement
    • Status: Open
    • Priority: Normal
    • Resolution: Unresolved
    • Affects Version/s: 4.16.0, 5.0.0
    • Fix Version/s: None
    • Component/s: Installer
    • Labels:
    • Environment:

      Ubuntu 14.04, Apache2 webserver, using reverse proxy. Artifactory installed as debian package.


      As a user, I run a fairly standard install of Artifactory as a debian package. In this set-up, Tomcat is linked from /var/opt/jfrog/artifactory/tomcat to /opt/jfrog/artifactory/tomcat.

      Using a standard install for a single service server, I kept /opt fairly small (6gb). This should be fine for installation and upgrade of Artifactory. As we're testing, a user attempted to upload a large .tar.gz file via the UI (1.6gb). this failed due to file size limitations in the UI. I advised to upload using curl and the API. This also failed.

      Checking, I saw that /opt was full. Further analysis showed MIMEXXX.txt files in /opt/jfrog/artifactory/tomcat/temp. These appear to be created during transactions. These appear to clean-up automatically, however, when the disk becomes full, clean-up does not occur.

      I propose Artifactory use a more standard Linux install set-up. large transient files should be kept in /var or /tmp. This will protect users from large transaction files filling /opt

      Also, I would suggest documenting this in the meantime. I have used a workaround of creating a symlink from /opt/jfrog/artifactory/tomcat/temp -> /var/opt/jfrog/artifactory/tmp/tomcat/. This functions well, but adds an extra step to installation.




            • Assignee:
              jchittum John Chittum
            • Votes:
              5 Vote for this issue
              10 Start watching this issue


              • Created: