[GH-ISSUE #484] Cache retention & purge

kerem commented

2026-03-15 15:27:17 +03:00

Owner

Originally created by @w3blogfr on GitHub (Aug 9, 2024).
Original GitHub issue: https://github.com/flyimg/flyimg/issues/484

Originally assigned to: @sadok-f on GitHub.

Hello,

I would like to know how local file cache is cleaned.

I see we can configure header_cache_days for browser, but are you also using this value to delete file after x days?

In some other questions, I saw you advice some people to clean the folder manually so I have some doubt about the cache cleaning mechanism?

Could you clarify how it's working?

Thanks in advance.

Originally created by @w3blogfr on GitHub (Aug 9, 2024). Original GitHub issue: https://github.com/flyimg/flyimg/issues/484 Originally assigned to: @sadok-f on GitHub. Hello, I would like to know how local file cache is cleaned. I see we can configure header_cache_days for browser, but are you also using this value to delete file after x days? In some other questions, I saw you advice some people to clean the folder manually so I have some doubt about the cache cleaning mechanism? Could you clarify how it's working? Thanks in advance.

kerem

2026-03-15 15:27:17 +03:00

closed this issue
added the
enhancement

question
labels

kerem commented

2026-03-15 15:27:39 +03:00

Author

Owner

@sadok-f commented on GitHub (Aug 12, 2024):

Thank you @w3blogfr for opening this issue.
I'm currently on vacation until the end of August.
As soon as I get back I will check it out.

@sadok-f commented on GitHub (Aug 12, 2024): Thank you @w3blogfr for opening this issue. I'm currently on vacation until the end of August. As soon as I get back I will check it out.

kerem commented

2026-03-15 15:27:45 +03:00

Author

Owner

@sadok-f commented on GitHub (Aug 27, 2024):

Hi @w3blogfr,
sorry for taking so long to answer your question, currently, there is no mechanism that deletes the cache from the server side after x days, the header_cache_days is only used on the browser side.
I'm still thinking of cronjob or a service to be configured inside the container that does that.
I'll let you know once it gets implemented.

@sadok-f commented on GitHub (Aug 27, 2024): Hi @w3blogfr, sorry for taking so long to answer your question, currently, there is no mechanism that deletes the cache from the server side after x days, the `header_cache_days` is only used on the browser side. I'm still thinking of cronjob or a service to be configured inside the container that does that. I'll let you know once it gets implemented.

kerem commented

2026-03-15 15:27:50 +03:00

Author

Owner

@tecnologiascds commented on GitHub (Aug 28, 2024):

Hi @w3blogfr, sorry for taking so long to answer your question, currently, there is no mechanism that deletes the cache from the server side after x days, the header_cache_days is only used on the browser side. I'm still thinking of cronjob or a service to be configured inside the container that does that. I'll let you know once it gets implemented.

Hello @sadok-f Thanks for all the work.

Taking advantage of this issue, I would also like to propose an auto-purge for the images stored in the tmp /var/www/html/var/tmp/ folder.

We use imgfly to serve a large number of images, and every 4 to 5 hours, I have to manually delete the contents of the tmp folder because we run out of disk space.

Message: Warning: file_put_contents(/var/www/html/var/tmp/original-d576f4c96a28336b947f23db080c63bd): Failed to open stream: No space left on device

It would be very useful if the images could be automatically deleted either after they are generated or at regular intervals.

Thanks so much

@tecnologiascds commented on GitHub (Aug 28, 2024): > Hi @w3blogfr, sorry for taking so long to answer your question, currently, there is no mechanism that deletes the cache from the server side after x days, the `header_cache_days` is only used on the browser side. I'm still thinking of cronjob or a service to be configured inside the container that does that. I'll let you know once it gets implemented. Hello @sadok-f Thanks for all the work. Taking advantage of this issue, I would also like to propose an auto-purge for the images stored in the tmp /var/www/html/var/tmp/ folder. We use imgfly to serve a large number of images, and every 4 to 5 hours, I have to manually delete the contents of the tmp folder because we run out of disk space. `Message: Warning: file_put_contents(/var/www/html/var/tmp/original-d576f4c96a28336b947f23db080c63bd): Failed to open stream: No space left on device` It would be very useful if the images could be automatically deleted either after they are generated or at regular intervals. Thanks so much

kerem commented

2026-03-15 15:27:55 +03:00

Author

Owner

@sadok-f commented on GitHub (Aug 29, 2024):

@tecnologiascds @w3blogfr in the latest version 1.4.6 I've added a cronjob that purges the folder var/tmp
it can be configured in the config/parameters.yml file by cronjob_cleanup_interval and enable_cronjob_cleanup (enabled by default)
@tecnologiascds could you please give it a try?

@sadok-f commented on GitHub (Aug 29, 2024): @tecnologiascds @w3blogfr in the latest version [1.4.6](https://github.com/flyimg/flyimg/releases/tag/1.4.6) I've added a cronjob that purges the folder var/tmp it can be configured in the `config/parameters.yml` file by `cronjob_cleanup_interval` and `enable_cronjob_cleanup` (enabled by default) @tecnologiascds could you please give it a try?

kerem commented

2026-03-15 15:28:00 +03:00

Author

Owner

@tecnologiascds commented on GitHub (Aug 29, 2024):

@tecnologiascds @w3blogfr in the latest version 1.4.6 I've added a cronjob that purges the folder var/tmp it can be configured in the config/parameters.yml file by cronjob_cleanup_interval and enable_cronjob_cleanup (enabled by default) @tecnologiascds could you please give it a try?

Hello @sadok-f
I have cloned the Git repository and executed the Dockerfile to generate the Flyimg image because when I tried deploying the image from Docker Hub using version 1.4.6, the footer of the index page kept showing version 1.4.5. I thought this might be an error uploading the image.

After doing this, the 1.4.6 version is now displayed. However, I configured the parameter.yml file to run the task every 15 minutes, but the content of /var/tmp is not being deleted.

This is my config
enable_cronjob_cleanup: true
cronjob_cleanup_interval: "*/15 * * * *"

Thanks so much

@tecnologiascds commented on GitHub (Aug 29, 2024): > @tecnologiascds @w3blogfr in the latest version [1.4.6](https://github.com/flyimg/flyimg/releases/tag/1.4.6) I've added a cronjob that purges the folder var/tmp it can be configured in the `config/parameters.yml` file by `cronjob_cleanup_interval` and `enable_cronjob_cleanup` (enabled by default) @tecnologiascds could you please give it a try? Hello @sadok-f I have cloned the Git repository and executed the Dockerfile to generate the Flyimg image because when I tried deploying the image from Docker Hub using version 1.4.6, the footer of the index page kept showing version 1.4.5. I thought this might be an error uploading the image. After doing this, the 1.4.6 version is now displayed. However, I configured the parameter.yml file to run the task every 15 minutes, but the content of /var/tmp is not being deleted. This is my config `enable_cronjob_cleanup: true` `cronjob_cleanup_interval: "*/15 * * * *"` Thanks so much

kerem commented

2026-03-15 15:28:05 +03:00

Author

Owner

@sadok-f commented on GitHub (Aug 29, 2024):

Hi @tecnologiascds
yes, there's an issue building the image with the right version, it keeps showing an older version despite the current version being updated, I'm planning to look into it.
when you update the cronjob_cleanup_interval, you must wait until the cronjob's next run, which defaults to 5 hours (in order to read the new interval value and update the crontab settings).
otherwise you can launch it from the container manually:

docker exec flyimg ./cleanup-tmp.sh

@sadok-f commented on GitHub (Aug 29, 2024): Hi @tecnologiascds yes, there's an issue building the image with the right version, it keeps showing an older version despite the current version being updated, I'm planning to look into it. when you update the `cronjob_cleanup_interval`, you must wait until the cronjob's next run, which defaults to 5 hours (in order to read the new interval value and update the crontab settings). otherwise you can launch it from the container manually: ```sh docker exec flyimg ./cleanup-tmp.sh ```

kerem commented

2026-03-15 15:28:10 +03:00

Author

Owner

@tecnologiascds commented on GitHub (Aug 30, 2024):

Hi @tecnologiascds yes, there's an issue building the image with the right version, it keeps showing an older version despite the current version being updated, I'm planning to look into it. when you update the cronjob_cleanup_interval, you must wait until the cronjob's next run, which defaults to 5 hours (in order to read the new interval value and update the crontab settings). otherwise you can launch it from the container manually:
docker exec flyimg ./cleanup-tmp.sh

Hi @sadok-f
It works perfectly I changed the cronjob_cleanup_interval, and after the first execution, it is now cleaning every 15 minutes.

Would you also recommend a similar cron job to purge the cache, or are you working on a different system?

Thanks so much

@tecnologiascds commented on GitHub (Aug 30, 2024): > Hi @tecnologiascds yes, there's an issue building the image with the right version, it keeps showing an older version despite the current version being updated, I'm planning to look into it. when you update the `cronjob_cleanup_interval`, you must wait until the cronjob's next run, which defaults to 5 hours (in order to read the new interval value and update the crontab settings). otherwise you can launch it from the container manually: > > ```shell > docker exec flyimg ./cleanup-tmp.sh > ``` Hi @sadok-f It works perfectly I changed the `cronjob_cleanup_interval,` and after the first execution, it is now cleaning every 15 minutes. Would you also recommend a similar cron job to purge the cache, or are you working on a different system? Thanks so much

kerem commented

2026-03-15 15:28:15 +03:00

Author

Owner

@sadok-f commented on GitHub (Aug 30, 2024):

@tecnologiascds great to hear that.
regarding the cache, for now there are no plans to introduce a cronjob to purge it, as many users need the cached version to serve the images fast.
if you need to generate the images each time and there is no need for the cache, then you can disable it by setting disable_cache: true in the config/parameters.yml file.

@sadok-f commented on GitHub (Aug 30, 2024): @tecnologiascds great to hear that. regarding the cache, for now there are no plans to introduce a cronjob to purge it, as many users need the cached version to serve the images fast. if you need to generate the images each time and there is no need for the cache, then you can disable it by setting `disable_cache: true` in the `config/parameters.yml` file.

kerem commented

2026-03-15 15:28:21 +03:00

Author

Owner

@tecnologiascds commented on GitHub (Sep 2, 2024):

@tecnologiascds great to hear that. regarding the cache, for now there are no plans to introduce a cronjob to purge it, as many users need the cached version to serve the images fast. if you need to generate the images each time and there is no need for the cache, then you can disable it by setting disable_cache: true in the config/parameters.yml file.

Great We have disable on parameters.yml

Thanks

@tecnologiascds commented on GitHub (Sep 2, 2024): > @tecnologiascds great to hear that. regarding the cache, for now there are no plans to introduce a cronjob to purge it, as many users need the cached version to serve the images fast. if you need to generate the images each time and there is no need for the cache, then you can disable it by setting `disable_cache: true` in the `config/parameters.yml` file. Great We have disable on parameters.yml Thanks

Rows
Columns

[GH-ISSUE #484] Cache retention & purge #782