Framework: Error Warning: filesize() while using cron after upgrading Laravel 5.8

[Perh0rd]

Hi,

We recently have updated to Laravel 5.6 to 5.8 and we randomly have this error now while using cron to call some api endpoints as we did before :

Warning: filesize(): stat failed for storage/framework/cache/data/aa/ba/aabaeafdb90f0d93adc97d019d71de3fd2045953

in /public/index.php - line 55

$request = Illuminate\Http\Request::capture()

Do you have any idea why?

Thank you very much!

[laurencei]

What's the full stack trace?

My guess is a file permission error, where the cron user is different to the web user. Or secondly, its a 'race' condition, and you should probably use another cache system besides file.

[Perh0rd]

Hi @laurencei and thank you for your answer.

Here is the full stack trace : Here

Note that, the cron user is the same as the nginx user, we try every permission , every chown, chmod 777 and so on on folder, we changed the cron folder and the user of the storage folder.

We cleared cache, every of them config, routes, view, app.... We removed files manually, we call composer update and dump-autoload

A thing which is very strange is that the datetime of the file is after the datetime of the error, like the file do not exist at the time the request was called?! It was working fine on version 5.6, I really do not understand why now it's broken.

Sometimes the error is th fopen failed to open stream: No such file or director sometime it is the errorfilesize(), we try with wget, curl, same result.....

Thank you for your light

[driesvints]

Hey there,

Can you first please try one of the following support channels? If you can actually identify this as a bug, feel free to report back and I'll gladly help you out.

• Laracasts Forums
• Laravel.io Forums
• StackOverflow
• Discord
• Larachat
• IRC

Thanks!

[driesvints]

Also: please fill in the issue template next time. Thanks!

[Perh0rd]

I did not see issue template while creating the issue .

Moreover problem still occurs, not only on cron but everywhere...

I don't know if it's a bug or not, but there is clearly something not properly working with this last version.

[wtbloom]

I did not see issue template while creating the issue .

Moreover problem still occurs, not only on cron but everywhere...

I don't know if it's a bug or not, but there is clearly something not properly working with this last version.

Were you able to ever find any resolution to this issue? I am having the exact same problem after upgrading to 5.8

[foxinatardis]

I am actually having this issue in version 5.7

[devsi]

Exact same problem. We can't figure it out yet. Like, the EXACT same problem. Laravel 5.7

[wtbloom]

I still haven't been able to solve it. I ended up just caching on a Redis instance as opposed to the file system as a workaround.

[eberkund]

I am having the same issue randomly getting reported by Sentry

[gleandroj]

I am having the same issue too on my application.

[djohnston08]

@driesvints I am not sure this is a support issue. We are also seeing this on numerous projects. Considering this was not an issue in previous versions, it seems like a bug. Maybe not a serious bug, but it definitely feels like a regression. The problem is that it’s intermittent so it seems to be getting ignored. Is anyone going to look into this or should we just expect to to ignore it in the future?

[driesvints]

@djohnston08 can you please try a support channel first and then report back if that didn't help?

[jamiehd]

@driesvints I'm pretty sure this is a bug rather than a support issue. We're getting it too but it's very sporadic. It seems to be an issue with the file cache driver.

ErrorException
Warning: filesize(): stat failed for /var/www/x/storage/framework/cache/data/a2/db/a2db5ca42f2189b4ea48e92035d86e01956e31a7

[infostreams]

I'm seeing this issue too, and a related issue in the same section of code (also triggered from public/index.php, line 55 like above). Seems to be a race condition, somehow. I've attached two screenshots from my Sentry instance - hope it helps.

screenshot 2:

I'm convinced it's a bug, not a support issue. Some other process is working with the same file and deletes it while the "current" process already has a lock? I'm not sure what's going on here. I have both a queue runner and a bunch of scheduled tasks (via cron job) running, but we can exclude the scheduled tasks because that only runs once a day and these errors pop up on other times as well. I'm on a Mac, FWIW. Perhaps it's a hash collision?

[driesvints]

Okay, I'll re-open this. Appreciating anyone who could help look into this.

[infostreams]

Thanks! I'm at a loss for as to how a filesize() call could fail on a file after you've acquired a lock on it (first screenshot).

[infostreams]

Ok, so I thought (and read) about it a bit more. I think there might be one of two things happening here:

1. Whatever flock() does is advisory, meaning that maybe (?) you don't really get a file lock even if you do call flock(). So any competing process could theoretically just call unlink(), maybe to clean out the cache folder, and delete the file that we thought we had a lock on.

2. flock() operates on a file handle, not on a file name. Assuming that flock() get us an actual lock, not an advisory one, then the code above could still fail if we rename the file that we have a lock on. That wouldn't affect the lock, as the file itself still has the lock – the file just has a different name. However, in the code, after we obtain the lock, we try to do an operation on the file with the name as it was before the assumed rename. Since that file name no longer exists, it would fail - triggering this error.

My two cents on this. Not sure on how to best address them. Thoughts?

[masbenx]

it also happened on version 5.7

[jamiehd]

Well that screenshot has given me a thought - is everyone here using sentry?

I use sentry so maybe it's related...

[donnysim]

From the stacktrace, the original issue seems more like a ThrottleRequests cache failure than related with cron itself (suggesting it runs the cron via url). Using file store even sessions sometimes can throw an exception of file not found and that's present for quite some time, minimum from laravel 5.2, though probably present in all versions.

[markgukov]

Well that screenshot has given me a thought - is everyone here using sentry?

I use sentry so maybe it's related...

Yep, using Sentry here.

[jamiehd]

I wonder if its related to this: https://github.com/getsentry/sentry-laravel/issues/254

[Rishats]

Laravel 6.10.1 - same problem.

[driesvints]

@Rishats are you using sentry-laravel? Can you try upgrading to 1.4.0 to see if that fixes your problem?https://github.com/getsentry/sentry-laravel/issues/254#issuecomment-543558493

[Rishats]

@Rishats are you using sentry-laravel? Can you try upgrading to 1.4.0 to see if that fixes your problem?getsentry/sentry-laravel#254 (comment)

I use https://packagist.org/packages/sentry/sentry-laravel

composer.lock

"name": "sentry/sentry-laravel",
"version": "1.5.0",
...

[andypa]

We are using Sentry as well. The error occured the first time, when following packages in our installation were updated. Some are internal packages so I just listed the public ones:

| Package | From | To|
| --- | -- | -- |
| aws/aws-sdk-php | 3.130.3 | 3.132.1 |
| egulias/email-validator | 2.1.13 | 2.1.14 |
| facade/ignition | 1.13.1 | 1.14.0 |
| laravel/nova | v2.9.2 | v2.9.3 |
| sentry/sdk | 2.0.4 | 2.1.0 |
| sentry/sentry | 2.2.6 | 2.3.0 |
| phpunit/phpunit | 7.5.18 | 7.5.20 |

The sentry/sdk had following changes:
Added: guzzlehttp/psr7 and symfony/polyfill-uuid
Removed: ramsey/uuid and zendframework/zend-diactoros

I'm now trying to upgrade to sentry/sentry-laravel 1.5.0 to check if that makes a difference.

[esbenp]

This error started happening to us right after we made some changes to enable persisting Horizon data across deploys. We made a separate Redis cache database, ala this change here https://github.com/laravel/laravel/commit/c3b99e971cd9d8213ada259b9f624a8f70ddd57b

We just reverted it back so the cache uses the default connection and so far no more errors have appeared, although it has not been in production for long enough to say its fixed. If this is the case then maybe the above commit can explain why this started occurring around 5.8??

[esbenp]

Update: the above mentioned fixed has removed the error for us. So maybe its related to having a redis database for cache thats not the default one?

[andypa]

Update: the above mentioned fixed has removed the error for us. So maybe its related to having a redis database for cache thats not the default one?

We don't use redis at all and the same error occurs.

[driesvints]

@esbenp are you using sentry as well?

[esbenp]

Yes

[driesvints]

Since everyone here is using the same library I think it's safe to say that the problem probably lies within there and not Laravel. Please follow along with the issue here: https://github.com/getsentry/sentry-laravel/issues/254