-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MiniMagick Filling up /tmp/ directory. #40
Comments
Thanks for looking into this, @scande3! We've seen that before so we're eager to hear more. |
Yes, good catch. Another way to solve this problem is by using tmpreaper. http://manpages.ubuntu.com/manpages/hardy/man8/tmpreaper.8.html -Justin On Wed, Jul 30, 2014 at 1:39 PM, Michael J. Giarlo <[email protected]
|
Added the following to my gemfile:
With a small sample size thus far of 13 objects, can confirm that I am no longer having my /tmp/ folder spammed with leftover objects. I'll post in their pull request as well. If they don't fix it and don't post a reason for not merging, would it be possible to point to the corrected code somehow? (Even if that means hydra-labs keeps a branched copy?). I'll also be continuing my derivative migration later today so will be running it on a few thousand more records to report any issues. @jcoyne - Thanks! Perhaps good to have running as well regardless of this fix and didn't know about that. |
Just to update: he made a more recent pull request with the Tempfile fix at minimagick/minimagick#236 . I haven't tested it yet though I'll update to point to his new branch shortly. |
Fixed by minimagick/minimagick#248 which was released as 4.0.0. Can we close this now? |
We're still encountering this issue using minimagick 4.2.10. We rely on a cron script to delete the temp files |
Are the people running into problems using Resque to process jobs in the background? I had them same problem for a while until I added RUN_AT_EXIT_HOOKS to my configuration. There is more information at resque/resque#1167. |
Yes, and we document this pattern in the Sufia README as well. (Thanks for that, @narogers!) |
I was running derivative creation on the ~75k objects in our repository. However, suddenly, all of my derivatives started error-ing and the AVI Processing server reported it had no space left on its hard drive. Looking at /tmp/, there are tons of files like: mini_magick20140730-1251-4a7xzf.jpg that ate up all of the available space (~60 GB of them).
I recalled that when using MiniMagick in the past, I was using a specific unmerged pull request from someone else for that exact issue in the past (though I stuck with RMagick in the end due to other image processing bugs MiniMagick has). Regardless, the relevant unmerged pull request is: minimagick/minimagick#188
Once the current backlog of ~2k remaining failed objects finishes, I'll attempt to use that old pull request to confirm it fixes the issue as it did in the past. Assuming it does, not sure if the best course of action is to pressure MiniMagick about accepting it to fix there bug or just using that unmerged version of the code?
To duplicate the jpg spam, just create a thumbnail derivative from a tif and check your /tmp/ directory. These files will get deleted upon a restart (by default) but MiniMagick leaving them behind when done with them just doesn't seem like correct behavior.
The text was updated successfully, but these errors were encountered: