tempthumb inside entry directory contains what?
It’s occupying lots of space.
Is it safe to delete those files?
path is: /opt/kaltura/web/content/entry/tempthumb/0
& kaltura_api_v3.log file generating too much logs. Log rotator is working fine but rotates only once a day, I think that’s not enough. What should I do to control disk space.
Please see: Tempthumb not empty
As for log verbosity, check the value of the *.priority.priority directives in /opt/kaltura/app/configurations/logger.ini, if it’s set to 7 [DEBUG], you can reduce it to 4 and reload Apache, which would result in less output being written to kaltura_api_v3.log.
Hi Jess
Thanks for replying & sharing link. I want to know is it safe to delete only files inside folders or I can delete any random folder also?
I should delete:
/opt/kaltura/web/content/entry/tempthumb/0/10
or
/opt/kaltura/web/content/entry/tempthumb/0/10/*
& I have checked the value of the *.priority.priority directives in /opt/kaltura/app/configurations/logger.ini which is already at 4.
kaltura_api_v3.log is creating around 20-24GBs per day.
Please suggest
Thanks
These directories will be recreated as needed so long as /opt/kaltura/web/content/entry/tempthumb is set to provide both the ‘kaltura’ and the apache user [‘apache’ in RHEL/CentOS, ‘www-data’ in Debian/Ubuntu] with writing permissions so you can delete the sub dirs if you wish but you can also run something like:
# find /opt/kaltura/web/content/entry/tempthumb -type f -exec rm {} ;
Which would only delete files under that dir and keep the sub dirs in place. With find you can also remove files older than a certain date or larger than a certain size but as I said, so long as there are write permissions on the parent dir, it’s safe to simply delete recursively.
As for the api_v3.log, yes, a lot of output is being written to it, even with the verbosity level set to 4. You can just rotate it at shorter intervals. Of course, you have to make sure to reload Apache if you delete rather than truncate it.
Hi Jess
Thanks for the valuable information but I am facing some issues after deleting cache.
I am not sure if that’s due to deleting cache or not but would love to hear from you.
We are using FOTOMOTO to work with some images from Kaltura. Fotomoto widget can’t process that image & returns error “The photo is private”
We also discovered that browser console returns such error https://goo.gl/ASGRNB when we click on Buy Card, Buy Print or eCard.
Below is the direct link which also shows error.
https://content2.babyflix.net/p/101/thumbnail/entry_id/0_xt3r7tid/width/type/1/quality/100
Is it because of deleting tempthumb files?
You’re most welcome, of course.
I am not familiar with FOTOMOTO so I cannot tell you how it works but there is nothing wrong with the thumbnail retrieved from https://content2.babyflix.net/p/101/thumbnail/entry_id/0_xt3r7tid/width/type/1/quality/100.
Like I said, the tempthumb is meant for caching, deleting it would simply mean the thumb would be regenerated upon request.
I get the thumbnail image just fine in all my browsers and more importantly, when using wget:
$ wget https://content2.babyflix.net/p/101/thumbnail/entry_id/0_xt3r7tid/width/type/1/quality/100
–2017-07-24 17:06:13-- https://content2.babyflix.net/p/101/thumbnail/entry_id/0_xt3r7tid/width/type/1/quality/100
Resolving content2.babyflix.net (content2.babyflix.net)… 45.56.84.64
Connecting to content2.babyflix.net (content2.babyflix.net)|45.56.84.64|:443… connected.
HTTP request sent, awaiting response… 200 OK
Length: 123664 (121K) [image/jpeg]
Saving to: ‘100’
100 100%[=============================================================>] 120.77K 293KB/s in 0.4s
2017-07-24 17:06:14 (293 KB/s) - ‘100’ saved [123664/123664]
jess@jessex:~$ file 100
100: JPEG image data, JFIF standard 1.01, resolution (DPI), density 72x72, segment length 16, comment: “Processed By eBay with ImageMagick, z1.1.0. ||B2”, baseline, precision 8, 1200x1600, frames 3
So I believe your issue has to do with local browser caching or perhaps CDN caching.
