Auto delete image doesn't work

[Andy]

👉Fill out this template accordingly with the issue you are experiencing. Add relevant files if needed. 🚧🚦Don't @mention to grab attention. Don't edit the titles of this template. Remove this paragraph when done.

🎯Description of the issue

We upload an image, and set that image to be auto-deleted within 3 mins, we waited more than 30 mins and the image not deleted.

▶🚶‍Reproduction steps

1. Go to https://site.pictures
2. Upload an image, and set a 5 minutes auto-delete
3. Wait 5 minutes and the image is not deleted.

😢Unexpected result

Auto-deleted images are not deleted.

📃Error log message

No error log, how can I see the error logs?

 

[Rodolfo]

Can you confirm if the actual image files aren't being deleted? Maybe is just a CDN cache or something like that.

 

[Andy]

Pretty sure, I checked the file that supposed to be deleted is still sitting on the file system, and we're not using any CDN.

 

[Rodolfo]

I need server access to debug it.

Send access to REDACTED (include a link to this topic).

 

[Andy]

Sent. Cheers

 

[Andy]

Just checking if there's any update?

 

[Rodolfo]

Checking the database, it seems that this stopped working on Jun 10 as that's the most recent record.



At the images table, the expiration_date_gmt is not being filled. At the demo, this field is being populated with the target date to delete so I'm guessing that you did some editing that broke this functionality. Others aren't bringing this issue, so I doubt that it is a bug in the software.

Check the image https://site.pictures/image/UiETn it holds image_expiration as PT5M but the actual expiration_date_gmt is null.

 

[Andy]

I didn't do any modifications. How can we remedy that issue?

 

[Rodolfo]

I'm sorry but you will have to find the error on your own. This is not something affecting other installations, so it could be anything from wrong system settings up to broken dependencies. I'm sorry but it takes me too much time do debug this kind of stuff, and since it doesn't seem to be affecting other users I won't classify it as a bug.

Try updating the stack (PHP and others), try with a clean install, try it in another machine, etc. If you show me a bunch of installations with the issue I could start an investigation.

 

[Andy]

Is there any error log I can start with?
I'm pretty sure we didn't do any changes on both Chevereto & Webserver/PHP/SQL.
Or can you create a SQL query to remedy this issue? Is this a database corrupt or what?
We have no clue on what's the error.
Will clean install remove all database & images and start from brand new site?

 

[Andy]

Update:

I upgraded to PHP Version 7.3.18, now running on fcgi.

Tested to upload 2 images and now I can see the image_expiration_date_gmt has been added, but the image still not deleting after 5 mins?

I think the others might have this issue too but they just simply not noticing it.
We also just noticed this issue after more than a month.

 

[Rodolfo]

The expiration_date_gmt is the date when the image expires, if the system detects that the image has expired it will issue a delete queue that gets triggered when you access the website. From there, other sub-systems could also fail.

1. On the null DB, it could be related to built-in datetime functions, perhaps the compiled PHP version has issues on timezones or whatnot
2. On the actual file deletetion, check the queues table it should have a record indicating an issue with the storage
3. Also check the deletions table, if the record is there then there a false positive in the filesystem

Like I said, is very complicated. I recommend you to update to latest stable releases.

 

[Andy]

The expiration_date_gmt is the date when the image expires, if the system detects that the image has expired it will issue a delete queue that gets triggered when you access the website. From there, other sub-systems could also fail.

1. On the null DB, it could be related to built-in datetime functions, perhaps the compiled PHP version has issues on timezones or whatnot
2. On the actual file deletetion, check the queues table it should have a record indicating an issue with the storage
3. Also check the deletions table, if the record is there then there a false positive in the filesystem

Like I said, is very complicated. I recommend you to update to latest stable releases.

We're running Chevereto v3.15.2 which is already latest stable version.
When we click check for updates, it says This website is running latest Chevereto version
Do you have a newer version for us to try?
Have you had a chance to look again after we do the PHP upgrade?

 

[Rodolfo]

Chevereto is just an script running on top of your server, literally there are dozen things that could be failing. As this issue is not preventing the system to work, the script layer is not triggering any exception so chances are that something is broken at server layer.

I could debug it on your server, but I really prefer if you simply update the stack.

 

[Andy]

We have done PHP stack update from 5.6 to 7.3 and the expiration_date_gmt now exist, but the auto deletion not working.

Can we set the debug level and get a clue somewhere to find where it fails?

 

[Rodolfo]

I will try to get a look into it within this week.

 

[Andy]

Thanks Rodolfo, let me know if you need any assistance from my end, happy to provide server logs if necessary.

 

[Rodolfo]

Please acknowledge that the system has permission requirements indicated here: http://v3-docs.chevereto.com/setup/requirements.html#file-permissions



I removed the files and it worked again.

Please keep this in mind in the future.

 

[Andy]

Hi Rodolfo, thanks and appreciate for your thorough investigation.
Pretty sure those permissions were already granted when we setup the Chevereto initially.

Any idea why those permissions has been altered? Such as running auto update perhaps?

And do you think the missing expiration_date_gmt on php 5.6 was caused by this permission issue as well or that's another issue indeed?

 

[Rodolfo]

No, I don't have any idea.