After resolving an error that was causing my log files to explode (2+ GB log files all full of the same exception log), I deleted the affected log files to avoid having it eat up unnecessary space. This was an error that was a couple of days old, and it affected multiple log files.
Since deleting the log files, however, it looks as if laravel has stopped logging anything. The daily log for the day I made the deletion seems to have stopped logging at the moment I deleted the older daily files, and no new daily files have been created since.
I've rerun composer install, artisan dump-autoload, artisan clear-compiled, and artisan cache:clear, to no avail. The permission settings all look fine as near as I can tell, and are assigned to the correct user. There were no configuration changes made at all, literally the only difference was in deleting the old daily log files.
Can anybody point me in the right direction with this? Can provide more information as necessary if I'm missing anything relevant.
Turns out this wasn't a logging error at all; turns out the problem was my cron scheduler got disabled and key processes weren't running. Different problem to solve, but glad to know I didn't break logging.
Related
I am using parallel testing addon for phpunit, paratest, with a Laravel application to speed up the execution of our testsuite.
This works most of the time but occasionally I get the following failure.
League\Flysystem\Exception: Impossible to create the root directory "/codebuild/output/src0123456/src/github.com/org/repo/storage/framework/testing/disks/local". file_get_contents(/codebuild/output/src0123456/src/github.com/org/repo/.env): failed to open stream: No such file or directory
/codebuild/output/src0123456/src/github.com/org/repo/vendor/league/flysystem/src/Adapter/Local.php:112
/codebuild/output/src0123456/src/github.com/org/repo/vendor/league/flysystem/src/Adapter/Local.php:78
/codebuild/output/src0123456/src/github.com/org/repo/vendor/laravel/framework/src/Illuminate/Filesystem/FilesystemManager.php:167
/codebuild/output/src0123456/src/github.com/org/repo/vendor/laravel/framework/src/Illuminate/Support/Facades/Facade.php:261
/codebuild/output/src0123456/src/github.com/org/repo/vendor/laravel/framework/src/Illuminate/Support/Facades/Storage.php:70
/codebuild/output/src0123456/src/github.com/org/repo/tests/TestCase.php:42
The failure on line 42 relates to this line which is creating the local storage folder for testing.
Storage::persistentFake();
I think the second half of the error that mentions the .env file is unrelated as the exception picks the last logged error rather than the error related to the failure.
This only happens every now and again so it must be a sequence of operation or timing issue.
The tests are running and failing inside an AWS codebuild environment against php 7.3 and 7.4.
Anyone have any ideas?
Incase anyone else comes across this, it was resolved by creating the test storage directory before executing the tests.
mkdir -p storage/framework/testing/disks/local
vendor/bin/paratest
It's a little brittle but so far has worked perfectly for us.
From my experience this is usually not an issue with the file system. Most of the times I had a test not cleaning up correctly.
Depending on the file system and Paratest your tests are executed in a different order and then this errors happens.
There are a few things you can do to track this down:
Enable --debug mode when executing the tests on your build environment and check all the test that were executed before.
As of PHPUnit 7.3 use --order-by=random locally to execute your tests in a different order then they appear when reading from the file system. Execute it a few times, maybe you can then simulate this locally.
I see that you're using Flysystem: try to execute the tests with the Memory filesystem adapter to make sure it is really not a file system problem.
Make sure that every test creates the filesystem layout before (Testcase::setUp()) and cleans it when shut down (TestCase::teatDown()), otherwise one test can have an influence on another.
Make sure your tests don't depend on values that may change. For example I had problems with tests that involved dates and I've executed tests on Jenkins at 23:59 and they failed, because the date switched to the next day. In those cases pass a date to work with through the test.
I've got a real head-scratcher for you! I've been working on a Laravel 5.4 application for quite some time now and up until yesterday I had been able to:
develop on my local machine [still works flawlessly],
push my changes to my BitBucket repo [still okay here],
and would subsequently pull those changes to my shared hosting server (RedHat) [still running smoothly],
I then run my dependency managers (npm and composer) to get the project in place and functional
there is some matter with clearing various caches:
php artisan view:clear
php artisan route:clear
php artisan cache:clear
composer dump-autoload
and finally move my '/public' folder to the web root and update index.php to point back to the 'bootstrap/autoload.php' in main project structure,
I am aware there is likely another or several steps I am missing, but I am unsure what they are...
All that being said, I've attempted to deploy a number of applications using Laravel lately and I always seem to run into the same issue come time to deploy an application to production. I've read 30+ tutorials on the matter and nothing seems to explain the issue why my site isn't working any more.
I've checked the error log file maintained by Apache, it's empty.
Was wondering if it's a permissions issue, doesn't seem to be the case (all folders set to 775 and files set to 664 as specified by various sources and owned by serverName:userName)
Browser console simply shows a 500 server error.
All I see if "Whoops, looks like something went wrong." twice.
There must be some way to show better error details (config debug setting already set to true)
Any suggestions at this point would be beneficial to send me looking in the right direction!
======= UPDATES =======
For the sake of thoroughness, and that this save others from severe headaches, I'll be posting actions taken here.
Following tutorial mentioned by #user123456 (permissions applies)
Generate new key for application
Run php artisan config:clear
Off to the races, answer to come!
You need to ensure you have a working .env file.
Once done, run php artisan key:generate to create a key for your application after which you should clear your application's cache as follows php artisan config:clear
I would never recommend using shared hosting for Laravel application. You will face lots of issues for permissions, composer and external dependencies. Instead, you can use cloud servers like DigitalOcean, Linode, vultr and deploy laravel application on them. If you don't know about linux and creating Stacks you can use Cloudways to deploy laravel.
https://dev.to/rizwan_saquib/deploy-laravel-application-on-cloud-easily-with-cloudways
I recently cloned a Laravel 5.4 project, run composer install, npm install and gulped. I was able to visit the log in screen of my application fine but of course couldn't log in since there was no database and consequently no users. So I set up the database and imported an sql file of some dummy data for my database. When I tried to log in for the first time the page hung for a bit and then displayed the above error. After that I couldn't even get to the log in screen as it kept displaying that error every time I refreshed. I tried deleting and readding an empty database but I still can't get to the log in screen. I can't even run any artisan commands as I get the same error in the console every time I try.
I've tried upping the memory_limit in the php.ini file to no avail, as every action just hangs for longer before displaying the same error message so I feel there must be some sort of infinite loop running somewhere.
I'm finding it quite tough to debug my code as I haven't added any production code, only run composer and npm commands. Any suggestions on how to debug / fix this would be greatly appreciated, many thanks.
This happened to me a couple of months ago. It might have happened in the process of a composer update, but I'm far from sure on that one. I've even updated my project to Laravel 5.3 and it still I can not get make:migration to work through Artisan. No the project it updated to 5.4 and it still do not work.
I've checked out this thread and I have the exact same problem. The symptoms were exactly the same, however the OPs solutions did not work for me.
I get no error or result in the terminal when running make:migrate.
I can generate any other file through Artisan it seems.
I tried to create a new model and pass the -m along with it. Didn't work.
I've checked permissions (and even changed migration folder), but didn't
help.
If I create my own migration-file the rest of the process through artisan works fine (migrate, DB-manipulation etc).
I've tried with different terminals and computers.
Since project were upgraded and even reinstalled I fear it has
nothing to do with the deep kernal. However maybe some sort of conflict from the higher level.
And in the last phase of my quest I tried to figure out what user interacting elements that can possibly effect the make:migration. Nothing worked.
I searched the web without any solution, then I gave up on that project and started to make my own migration files. However I now got some new hope when I saw that other thread.
After some troubleshooting I finaly managed to figure out the problem.
I narrowed it down to have something to do with the config/app.php-file.
Seems I in this project had typed in:
'timezone' => 'UTC+2'
This made creation of migration-files come to a halt without error messages. And it effected only the creation of migration-files (at least what I noticed).
I changed it to 'UTC' and it worked liked a charm again.
Note: the 'UTC+2' worked in the application and I never saw any other indications of errors regarding the rest of the app.php-file, or in the application in general.
Solution: When I instead used the parameters from this site it all worked perfectly again.
Just playing with Laravel 4 for the first time after using version 3 for a few projects but can't seem to get Artisan to work at all. I've done a bunch of searching and followed the troubleshooting steps I could find but no luck.
I've got Mcrypt installed
I had no bootstrap/compiled.php file to delete
I have the latest version of the framework from Github
I am on the latest version of Composer
When I try "composer update" I get this error:
Script php artisan optimize handling the post-update-cmd event returned with an error:
...with no extra information.
Trying to run "php artisan list" or any other artisan command just gives me no output at all.
Any ideas?
To summarise the discussion in the comments, we discovered that adding logging at the php.ini level revealed a PHP error that was not reported by the Composer console interface. I wonder whether you had installed Composer as root, and so some critical files required by Laravel were effectively invisible for a non-privileged user.
After running phpinfo, I noticed "--disable-mbregex" was part of the PHP configuration, meaning PHP was not compiled with the mbregex extension. My error logs were showing "Call to undefined function mb_regex_encoding".
Once PHP was recompiled with mb_regex_encoding, the issue went away.
If you are missing the /bootstrap/start.php file, you don't get helpful error messages from artisan and composer responds the same way. I went around and around trying solutions I found online and ultimately discovered this file was missing. I was back online as soon as I replaced it. I discovered this file was missing in my PHP error logs and artisan wasn't generating logs since it was unable to run.
I had a similar problem. Even the command $ php artisan --verson would not produce any output. Turned out, I had some code under app/start/global.php which was breaking under the CLI execution (but not breaking on the web side).
So that's another place to check for stuff! (app/start/global.php)
I was getting this problem, and it was because the subdirectories of storage did not yet exist.
Of course, these directories are created by the project-creating script, but they're quite easy to leave out of source control and so will be missing on a freshly cloned project. The .gitignore files are in there for a reason it would seem!
This problem occurred for me when there were files in the storage folder that were not writable for the current user. php artisan silently failed, without output. Changing permissions helped.