Did you run any update that could have caused this issue ?

The Illuminate\Contracts\ namespace only exists in L5, so I hightly doubt you have this error message on a L4 application.

RemiCollin said:

Did you run any update that could have caused this issue ?

The Illuminate\Contracts\ namespace only exists in L5, so I hightly doubt you have this error message on a L4 application.

The last update I did was 2+ days ago. The Laravel websites stopped working about 24 hours ago.

I did notice that specific namespace is a L5 namespace, but I get this error message on 3 L4 applications. One L5 application works fine.

I also find it weird that there's about 10% chance it works when reloading on one of the websites.

I suggest you hunt down any 3rd party package you use in your applications, they may have updated some of their dependencies to L5, which may be causing this mess, which is unlikely as composer should prevent this... Still that's the only logical explanation I can think off.

When it works, it's probably that it's rendering from the cache.

What happens when you run 'php artisan' on the broken apps ?

I cannot find any 3rd part package that should have any issues. Only one of the websites are using such, and I can't find any problems with it.

php artisan works just fine on the applications. The cronjobs have kept running in the background.

Well, maybe you can paste the full error log that leads to that Class not exists exception. Without it we can't go as far as guessing..

Sure. I changed the actual domain name to website.com in the path.

[2015-04-06 15:12:03] production.ERROR: exception 'ReflectionException' with message 'Class Illuminate\Contracts\Debug\ExceptionHandler does not exist' in /var/www/website.com/bootstrap/compiled.php:235
Stack trace:
#0 /var/www/website.com/bootstrap/compiled.php(235): ReflectionClass->__construct('Illuminate\Cont...')
#1 /var/www/website.com/bootstrap/compiled.php(205): Illuminate\Container\Container->build('Illuminate\Cont...', Array)
#2 /var/www/website.com/bootstrap/compiled.php(583): Illuminate\Container\Container->make('Illuminate\Cont...', Array)
#3 /var/www/website.com/bootstrap/compiled.php(353): Illuminate\Foundation\Application->make('Illuminate\Cont...')
#4 /var/www/website.com/bootstrap/compiled.php(695): Illuminate\Container\Container->offsetGet('Illuminate\Cont...')
#5 /var/www/website.com/bootstrap/compiled.php(695): Illuminate\Foundation\Application->boot()
#6 /var/www/website.com/bootstrap/compiled.php(7825): Illuminate\Foundation\Application->handle(Object(Illuminate\Http\Request), 1, true)
#7 /var/www/website.com/bootstrap/compiled.php(8432): Illuminate\Session\Middleware->handle(Object(Illuminate\Http\Request), 1, true)
#8 /var/www/website.com/bootstrap/compiled.php(8379): Illuminate\Cookie\Queue->handle(Object(Illuminate\Http\Request), 1, true)
#9 /var/www/website.com/bootstrap/compiled.php(11045): Illuminate\Cookie\Guard->handle(Object(Illuminate\Http\Request), 1, true)
#10 /var/www/website.com/bootstrap/compiled.php(657): Stack\StackedHttpKernel->handle(Object(Illuminate\Http\Request))
#11 /var/www/website.com/public/index.php(49): Illuminate\Foundation\Application->run()
#12 {main} [] []

It really looks like the version of the Laravel framework in your vendor directory is the 5.0.x.

What have you got in the require section of this app's composer.json ?

"require": {
		"laravel/framework": "4.2.*"
	},

Try to run composer update and then artisan clear-compiled.

Done that. Same problem.

Did you try to search for the 'Illuminate\Contracts\Debug\ExceptionHandler' string in your project ? That might help you find out which part of the app is breaking things down.

RemiCollin said:

Did you try to search for the 'Illuminate\Contracts\Debug\ExceptionHandler' string in your project ? That might help you find out which part of the app is breaking things down.

There are literally no mention of it anywhere at all in any of the projects, except in the log.

Do you think there's been some sort of cache on the server that have somehow used the one L5 project and affected all the L4?

Maybe try to clear the composer cache (usually located in /home/user/.composer)

Then remove the vendor folder on the broken app, and run composer update for a clean install.

Also, just thinking about this, what is your stability requirement on the app's composer.json ? Just make sure it's set on 'stable'

Minimum is set to "stable", composer cache has been cleared.

Removed compiled.php, removed the vendor folder, did composer update and installed all that, still same issue.

It only happens on the production server, not locally...

I suggest you ask your server admin, sounds like something weird is happening, might be apache/nginx issue or something else. If it works locally, no reason it should't work on production, so I suspect some exterior factor causing this issue.

I'd restore my backup and troubleshoot from there. Test all on your dev server. If working on dev but not production, RemiCollin is right, check production server for something weird / changed.

I have the same error, something weird is that sometimes works, sometimes not, we are hosted at liquid web, any idea?

I suggest you post an issue to Laravel's github.

I too am facing the same issue. I have 2 Laravel 4.2 apps and 3 Laravel 5.0 apps on DigitalOcean droplet. Everything was going quite good since the last one year. After a recent server upgrade, both the Laravel 4.2 apps started throwing the above mentioned error while all the three Laravel 5 apps continue to work as usual.

I have just posted this issue on Github. Here's the link

https://github.com/laravel/framework/issues/8303

Thanks a lot. Happy I'm not the only one with this issue. I'm on DigitalOcean as well.

Do you have any OpCache enabled for that server instance (PHP OpCache for example since you're using PHP 5.5+)? There could a bug where OpCache is loading the wrong compiled.php from memory (L4 app loading L5 compiled.php) etc.

Could be worth checking indeed!

Still the strange thing is that it happens at the same time with 3 users so far, after a composer update, so my instinct move toward a composer/autoload issue.

Any news on it guys ?

i get this too - seems related to having laravel4 and laravel5 sites on the same apache. goto laravel4 site - works fine - goto laravel5 site, then back to any one of several laravel4 sites and bang 'Class Illuminate\Contracts\Debug\ExceptionHandler does not exist ' restart apache then fixes the problem

U says restarting apache fixed it ?

RemiCollin said:

U says restarting apache fixed it ?

yep seems to for me, until someone visits the laravel5 site again. i've now deactived my laravel5 site and the laravel4 sites seem to be stable

Do you use OpCache as crynobone suggested ?

PS : https://github.com/laravel/framework/issues/8303 .... no comment. I think someday I'll just stop contributing or helping people. Enough said, this guy pisses me off!!

I can confirm apache restart works, but since the L5 app is pretty popular, it doesn't take long until the L4 apps are no longer functional.

As for OpCache, I did the command php -r "opcache_reset();", but it had no effect.

What is your environment (server, php version, etc), do you use any tool as forge or envoyer ?

• Ubuntu 14.04.2 LTS (GNU/Linux 3.13.0-32-generic x86_64)
• PHP 5.5.9-1ubuntu4.7
• Apache/2.4.7 (Ubuntu)

Not using forge or envoyer.

I have the same stack (on my developpment server), with both L4 & L5 applications but couldn't replicate the issue (tried last L5 update and run few request on both l4 and l5 apps).

It must be able to replicate somehow, considering I'm not the only one with this exact issue.

Right now I'm not sure if I should create a new droplet at DO and try and set it up again (hopefully without the issue), or wait for an actual fix for this.

CentOS 6.6 32bit PHP 5.4.39 Apache/2.2.15

Well, if having your application running is time critical, I guess I would go for the first option.

jjrdev said:

CentOS 6.6 32bit PHP 5.4.39 Apache/2.2.15

We have nothing in common on that part, must be something else.

I'll try setting up a new droplet tomorrow. The L5 app (which is working) is really the one that needs to be working.

I saw in recent laravel5 commits that there were some changes involving the 'compiled.php' file location. Not sure if it's related but maybe that's worth a check.

Still, the fact that it works briefly after a apache restart makes it more likely to be a system issue I guess.

Tell us how it goes.

As for OpCache, I did the command php -r "opcache_reset();", but it had no effect.

OpCache doesn't run by default on commandline (CLI) unless you enabled it. It might be worth disabling the whole extension temporarily just to check if it is the cause of this error.

I saw in recent laravel5 commits that there were some changes involving the 'compiled.php' file location.

Shouldn't be the case, since L4 use bootstrap/compiled.php while L5 is either storage/framework/compiled.php or vendor/compiled.php (in separate folders).

Indeed, then opcache mixing up the files would be weird. But +1 on deactivating extension just to be sure.

I wonder if it could be some bug at the autoloading (composer) level ?

Disabled opcache (wasn't enabled in first place), but no change.

I did a sudo apt-get update and sudo apt-get upgrade, and I'm not sure if I just feel like there's a change, or if there actually is a difference.

Here's what I found out; right now there's no need to restart apache, but as long as I refresh the L4 app, it works. But once the L5 app is loaded, it breaks the L4. But right now, I don't have to restart apache each time.

I'm going to wait on creating a new droplet, as I really have better things to do with my time and money.

Just FYI, New Relic announced an update which should solve the issue: https://docs.newrelic.com/docs/release-notes/agent-release-notes/php-release-notes/php-agent-420295