Skip to content
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

[feature] persist the timing state of media-cleanup-every #3045

Closed
cdn0x12 opened this issue Jun 26, 2024 · 2 comments
Closed

[feature] persist the timing state of media-cleanup-every #3045

cdn0x12 opened this issue Jun 26, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@cdn0x12
Copy link

cdn0x12 commented Jun 26, 2024

Is your feature request related to a problem ?

It seems that the timer for media-cleanup-every get reset every time a gotosocial instance restarts. If this is true, it means that the media auto-cleanup will never take effect if the value of media-cleanup-every is greater than the interval at which the user update their GTS instance.

Is it possible to save the timer for media-cleanup-every, so that the GTS instance can have the media-cleanup-every interval set freely even in the case of frequent updates?

p.s. will #3042 fix this issue?

Describe the solution you'd like.

Persist the timing state of media-cleanup-every to db.

Describe alternatives you've considered.

It would also be helpful to add a corresponding note in the documentation.

Additional context.

Specifically, my GTS instance restarts approximately every 24 hours due to updates. After setting media-cleanup-every to 168h, my storage keeps increasing and seems to never be cleaned up.

@cdn0x12 cdn0x12 added the enhancement New feature or request label Jun 26, 2024
@tsmethurst
Copy link
Contributor

Just realized this is a duplicate of #2492, so I'll close this one. In the meantime, perhaps you could try just restarting GtS once every 8 days or so, to ensure the media cleanup runs, that would at least prevent your media size from getting out of control while we figure something out for storing the timing of jobs.

@tsmethurst tsmethurst closed this as not planned Won't fix, can't repro, duplicate, stale Jun 29, 2024
@cdn0x12
Copy link
Author

cdn0x12 commented Jun 29, 2024

Thanks, Will follow #2492 then :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants