I'm facing a login issue with my Laravel application deployed on Google Cloud Platform (GCP) Compute Engine. The database is also deployed on the same infrastructure. Here's what happens:
Not Found The requested URL was not found on this server. Apache/2.4.52 (Ubuntu) Server at 34.30.69.122 Port 80
I suspect the issue might be related to my database configuration. My current .env file likely has DB_HOST=localhost, which wouldn't work when the application is deployed.
Here's what I've tried so far:
I would appreciate any guidance on how to troubleshoot this further. Any suggestions on what might be causing the "Not Found" error after login and how to resolve it?
Solved! Go to Solution.
Based on the configuration you've shared, there are a couple of points that stand out and could potentially be causing the issue:
Your Apache configuration snippet shows <VirtualHost *:79>
, which means Apache is listening on port 79 for this virtual host. This is unusual because HTTP traffic typically runs over port 80 (or port 443 for HTTPS). Unless you have a specific reason for using port 79 and have configured your network and application to use this port, this might be the source of the problem.
Solution: If you intended to use the standard HTTP port, change the VirtualHost directive to listen on port 80:
<VirtualHost *:80>
After making this change, restart Apache to apply the configuration:
sudo systemctl restart apache2
If you're using a non-standard port by design, ensure that your requests to the Laravel application are explicitly targeting port 79 (e.g., http://34.171.170.110:79
). If not, and there's no specific reason to use port 79, switching back to the default port 80 (as mentioned above) is recommended.
Check Apache and Laravel Logs
Apache Logs: Check the Apache error logs (${APACHE_LOG_DIR}/error.log
) for any specific errors that could indicate why the request was not found. The error log might provide more details on what's going wrong.
Laravel Logs: Also, review the Laravel application logs in storage/logs/laravel.log
for any application-specific errors that might not be related to Apache but could cause the routing to fail.
Ensure Apache and PHP are Correctly Configured
PHP Module: Ensure that the PHP module is enabled in Apache. You can check this by running a2enmod php<version>
(replace <version>
with your PHP version, e.g., php7.4
).
Server Restart: Every time you change the Apache configuration or enable a module, remember to restart Apache to apply the changes.
Firewall or Port Blocking
If you're using a non-standard port (like 79), ensure that your server's firewall or any network firewalls (including cloud provider firewalls) are configured to allow traffic on that port.
If the issue persists after verifying the port and ensuring Apache is correctly configured and restarted, consider simplifying the setup to diagnose the problem:
Static HTML File: Temporarily place a simple index.html
file in the /var/www/html/public
directory with basic content (e.g., <h1>Hello World</h1>
) and try accessing it via your browser. This can help confirm whether the issue lies with Apache serving files from the DocumentRoot
or if it's more related to Laravel's routing.
The "Not Found" error after entering login credentials suggests a problem with routing the request to the correct controller or view in your Laravel application. This could be due to route configuration issues, Apache server configuration, or less likely, database connectivity problems. Here's how to troubleshoot:
Database Connection:
Verify DB_HOST: If your database is hosted on the same Compute Engine instance as your Laravel application, DB_HOST=localhost
is correct. This configuration allows your application to communicate with the database through the local machine.
Credentials: Confirm that your database credentials (DB_USERNAME
, DB_PASSWORD
) in the .env
file are accurate.
Test Connectivity: You can test database connectivity directly from your Compute Engine instance using a command like mysql -u yourusername -p -h localhost yourdatabase
to ensure there's no broader connectivity issue.
Apache Configuration:
Document Root: Ensure the Apache document root is correctly set to the public
directory of your Laravel installation. This is crucial for proper routing in Laravel.
mod_rewrite: Confirm that Apache's mod_rewrite
module is enabled, as it's essential for Laravel's routing. Enable it with sudo a2enmod rewrite
if necessary.
Restart Apache: After making changes to the configuration, don't forget to restart Apache using sudo service apache2 restart
.
Laravel Configuration:
Environment: Make sure the APP_ENV
in your .env
file is set to production
and APP_DEBUG
is set to false
to avoid exposing sensitive information.
Routes: Check your routes with php artisan route:list
to ensure they are defined correctly.
Config and Route Cache: Clear your config and route cache with php artisan config:clear
and php artisan route:clear
to make sure Laravel is using the latest configuration.
Permissions:
File Permissions: Verify that the web server user (e.g., www-data
) has the necessary read and write permissions on the storage
and bootstrap/cache
directories.
Debugging:
Laravel Logs: Increase the verbosity of your Laravel logs by checking the storage/logs/laravel.log
file for any errors that might have been missed.
Browser Dev Tools: Use the Network tab in your browser's developer tools to inspect the request that's failing. This can provide clues about the issue.
Additional Tips:
APP_URL Setting: Use the APP_URL
setting in your .env
file to specify the full URL of your application, which can affect asset and route generation.
Version Control Review: If you're using version control (like Git), review recent changes to configuration files or routes that might have introduced the issue.
Load Balancer Configuration: If your deployment includes a load balancer, ensure it's correctly configured to forward requests to your Compute Engine instance(s).
for the APP_URL I added the external ip of the vm
when i run this line : php artisan route:list
i get
ReflectionException
Class "App\HTTP\Controllers\pendingcaseController" does not exist
at vendor/laravel/framework/src/Illuminate/Foundation/Console/RouteListCommand.php:234
230▕ if ($this->isFrameworkController($route)) {
231▕ return false;
232▕ }
233▕
➜ 234▕ $path = (new ReflectionClass($route->getControllerClass()))
235▕ ->getFileName();
236▕ } else {
237▕ return false;
238▕ }
+3 vendor frames
4 [internal]:0
Illuminate\Foundation\Console\RouteListCommand::Illuminate\Foundation\Console\{closure}()
+17 vendor frames
22 artisan:35
Illuminate\Foundation\Console\Kernel::handle()
but when i change the folder name app to App i see all the routes but i need to keep it as app in order to get the login screen to load. if it is okay with you would you like to do a teamviewer session with me to better assist me ? I would be very grateful for that
The error you're seeing with php artisan route:list
usually means Laravel can't find your pendingcaseController
. This is often due to a mismatch between namespaces, class names, and the way Laravel expects your files to be organized:
App\
. A controller named pendingcaseController
should live within the namespace App\Http\Controllers\pendingcaseController
.Here are some trouble shooting steps you can take:
Check Namespace & Class Name: Make sure your controller file is named PendingCaseController.php
(note the capitalization) and the class inside is declared as PendingCaseController
within the App\Http\Controllers
namespace.
Verify Directory: Your controller file should reside in the app/Http/Controllers
directory (if you haven't changed the default).
Fix 'app' vs. 'App' Issue: The easiest fix is to rename your app
directory to App
. If there's a specific reason you need to keep it lowercase, you'll have to delve into more complex configuration changes in composer.json
.
Clear Cache & Regenerate Autoload: After any changes, run these commands:
php artisan cache:clear
composer dump-autoload
thanks for your reply in your statement
this sounds more resonable : If there's a specific reason you need to keep it lowercase, you'll have to delve into more complex configuration changes in composer.json.
In a Laravel project, by default, the folder name for the application code (including controllers, models, and other PHP classes) is app, not App
from chatgpt
I mentioned case sensitive as possibility but the error is more likely related to the namespace declaration within your controller file or how you're referencing it in your routes or other parts of your application
The "Class not found" error, specifically "ReflectionException Class 'App\HTTP\Controllers\pendingcaseController' does not exist", typically indicates a mismatch in how your controller is defined versus how it's being referenced. Key areas to check include:
Namespace: The namespace at the top of your pendingcaseController.php
file should be namespace App\Http\Controllers;
. This declaration is crucial for Laravel to locate the file within its directory structure.
Class and File Names: PHP conventions dictate the use of PascalCase for class names (e.g., PendingCaseController
). The file name must exactly match the class name (PendingCaseController.php
), including case sensitivity.
Route Definition: In Laravel 8 and later, the way you reference your controller in routes should accurately reflect the namespace and class name.
Autoloading: Changes to class organization or naming necessitate running composer dump-autoload
to update Laravel's internal class mappings.
Troubleshooting Steps with an Emphasis on Case Sensitivity
Namespace Check:
pendingcaseController.php
.namespace App\Http\Controllers;
.Class and File Name Scrutiny:
PendingCaseController
, adhering to PascalCase.PendingCaseController.php
. Note that many systems are case-sensitive; thus, pendingcasecontroller.php
is not equivalent to PendingCaseController.php
.Route Verification:
use App\Http\Controllers\PendingCaseController;
Route::get('/pending-case', [PendingCaseController::class, 'methodName']);
Refresh Autoloading:
composer dump-autoload
in your terminal.would you like too check it with me via zoom share screen on the weekend ?
I was doing some debugging and I notice something
on the compute engine i added the following line of code in the controller that manages my login
and I get this
array:13 [▼ // app/Http/Controllers/AuthManager.php:25 "driver" => "mysql" "url" => null "host" => "localhost" "port" => "3306" "password" => "specialpassword" "unix_socket" => "" "charset" => "utf8mb4" "collation" => "utf8mb4_unicode_ci" "prefix" => "" "prefix_indexes" => true "strict" => true "engine" => null "options" => []]
The discrepancy you're observing in the configuration array between your local environment and the Compute Engine instance is indeed peculiar, especially since the database name and username are missing in the output on the Compute Engine instance. This suggests an issue with how the .env
file or the environment variables are being read or parsed in your production environment. Here are some steps to help you diagnose and resolve this issue:
.env
Entries:.env
variables:
DB_DATABASE=your_database_name
DB_USERNAME=your_database_username
=
signs. Note that values should not be surrounded by quotes unless they contain spaces.php artisan config:cache
, your application might be relying on cached configuration values. To clear the config cache, run:
php artisan config:clear
.env
values being used.Verify .env
File:
.env
file for any typos or incorrect formatting, especially around the DB_DATABASE
and DB_USERNAME
entries..env
file is present in your deployment environment, as it might be excluded by file transfer or version control systems.Clear Caches:
php artisan config:clear
php artisan cache:clear
Restart Servers (if applicable):
sudo systemctl restart php7.4-fpm
, adjusting for your PHP version.Environment Check:
php artisan tinker
and run dump(env('DB_DATABASE'));
to directly check if the .env
values are correctly loaded by Laravel.File Permissions: Verify that the .env
file has the correct permissions to be readable by the web server or PHP process.
Debugging Tools: Consider using Laravel's logging capabilities (Log::info()
) or temporarily inserting dd()
at strategic points to verify the application's runtime behavior regarding .env
value loading.
in response to : ''he discrepancy you're observing in the configuration array between your local environment and the Compute Engine instance is indeed peculiar, especially since the database name and username are missing in the output on the Compute Engine instance. This suggests an issue with how the .env file or the environment variables are being read or parsed in your production environment. Here are some steps to help you diagnose and resolve this issue:''
I recently fixed this isssue now i see the username and database name
i tried this line fo code : dump(env('DB_DATABASE')) i get null in response
Here are a few potential reasons and solutions for why env('DB_DATABASE')
might return null
:
1. Configuration Caching
One of the most common reasons for this behavior is Laravel's configuration caching. When you run php artisan config:cache
, Laravel caches the configuration values, and subsequent calls to env()
outside of configuration files will return null
. This is because, with configuration caching enabled, Laravel expects all environment variables to be accessed through the config files rather than directly via env()
calls.
Solution: Use the configuration value instead of the environment variable directly. For example, instead of env('DB_DATABASE')
, use config('database.connections.mysql.database')
. If you need to clear the configuration cache, you can run php artisan config:clear
.
2. Incorrect .env File Location or Permissions
If the .env
file is not in the root directory of your Laravel project or if it has incorrect permissions, Laravel might not be able to read it properly.
Solution: Ensure the .env
file is located in the root directory of your Laravel project and has the correct permissions (usually readable by the web server or PHP process).
3. .env File Parsing Issues
Sometimes, the .env
file might have formatting issues that prevent certain variables from being parsed correctly, such as spaces around the =
sign or missing values.
Solution: Double-check the .env
file for any formatting issues. Ensure there are no spaces around the =
sign, and all variables are correctly defined.
4. Overridden Environment Variables
In some server environments or through certain deployment processes, environment variables might be set or overridden at the server level or through other mechanisms outside of the .env
file.
Solution: Check your server's environment variable settings and any deployment scripts to ensure they are not overriding the DB_DATABASE
value.
5. Laravel Version Specific Issues
If you're using a specific version of Laravel, there might be version-specific issues or changes in how environment variables are handled.
Solution: Check the Laravel release notes for your version for any known issues or changes related to environment variable handling. Updating to the latest version of Laravel might also resolve the issue.
After checking these potential issues, remember to clear your configuration cache (php artisan config:clear
) to ensure your changes take effect. If you continue to experience issues, consider reviewing Laravel's documentation on configuration and environment variable handling for further insights.
here is a pic
The error message you're encountering when attempting to use Log::info();
in Laravel's Tinker is due to calling the info
method without any arguments. The Log::info()
method expects at least one argument: the message you want to log. This is why you're seeing the "Too few arguments to function" error.
Regarding the env("DB DATABASE")
returning null
, it seems there's a typo in your command. Instead of a space, you should use an underscore (_
) to match the environment variable name as defined in your .env
file. So, it should be env("DB_DATABASE")
.
Here is how to address both issues:
Correcting the Log::info()
Usage
To use Log::info()
correctly, you need to pass a message to it. Here's an example:
Log::info('This is a log message.');
This will log the message "This is a log message." to your default log channel, which is typically defined in your config/logging.php
file.
Correcting the env()
Usage
Make sure you're using the correct environment variable name with underscores instead of spaces. For example:
dump(env("DB_DATABASE"));
This should return the name of your database as defined in your .env
file, assuming that your configuration cache isn't causing issues (as mentioned in previous responses, env()
calls will return null
for any variable if the configuration is cached).
Additional Notes
Checking Database Configuration: Your use of config('database.connections.mysql.database')
correctly returned the database name ("crf_db"
), indicating that your Laravel application is successfully reading the database configuration from your config/database.php
file, which in turn reads from the .env
file or cached configuration.
Typo in config()
Calls: Be cautious of typos in your config()
calls (e.g., config('database.connectons.mysql. database')
seems to have a space before database
and misspells connections
as connectons
). Typos can lead to unexpected null
values because Laravel cannot find the specified configuration value.
Undefined Configuration Keys: Attempting to access a configuration value that doesn't exist (like config('database.connections.mysql.status')
) will return null
because there is no status
key in the default database connection configuration array.
can we run a live chat on a discord server or maybe zoom, google meets where I could share my screen with you cause I dont feel comfortable sharing sensitive information on here I sent you a private message some time ago did you find it? it was a link to my discord server. here is a pic of my .env and log attempt on tinker
Based on the output and issues you've encountered while using Laravel Tinker, here is how to address each point:
1. env("DB_DATABASE")
Returning null
The env("DB_DATABASE")
returning null
despite the .env
file having a DB_DATABASE
entry can be attributed to Laravel's configuration caching. When configuration caching is enabled (php artisan config:cache
), direct calls to env()
from your code or Tinker will return null
because Laravel loads environment variables into configuration values at the time of caching, and then env()
calls are not supposed to be used directly outside of configuration files.
Solution: Always access configuration values using the config()
helper function instead of env()
outside of the config files. For example, use config('database.connections.mysql.database')
to get the database name.
2. Logging Attempt in Tinker
Your attempt to log a message using Log::info('this is a log message.')
is syntactically correct. If you're not seeing the log entry, ensure you're checking the correct log file based on your LOG_CHANNEL
setting. Since your .env
shows LOG_CHANNEL=stack
, Laravel logs messages in the storage/logs
directory, typically within a file named laravel.log
.
3. Parse Error in Tinker
The parse error you encountered (PARSE ERROR PHP Parse error: Syntax error, unexpected T_ENCAPSED AND_WHITESPACE
) seems to be caused by a syntax mistake in your Tinker command. Ensure your commands are syntactically correct and try again. For example, the correct syntax to retrieve the database name from the configuration would be:
config('database.connections.mysql.database')
4. Correcting .env
File Entries
Your .env
file snippet shows some variables with spaces around the =
sign (e.g., APP_DEBUG= true
). The correct format for .env
entries does not include spaces around the equals sign. It should be like APP_DEBUG= true
. Ensure your
.env
file follows this format to avoid issues.
5. After Making Changes to .env
After making any changes to your .env
file:
Run php artisan config:clear
to clear the configuration cache.
Run php artisan cache:clear
to clear the application cache.
Optionally, if you're in a local or safe development environment, you can run php artisan config:cache
to regenerate the configuration cache with the updated values.
6. Verifying Log Entries
To verify that logging works as expected, after running Log::info('this is a log message.');
in Tinker, check the storage/logs/laravel.log
file for the new log entry. Ensure you have the necessary permissions to view and modify files in the storage/logs
directory.
Adjust your .env
file to correct the format, use config()
instead of env()
for accessing configuration values, especially after caching the configuration, and ensure your Tinker commands are syntactically correct to avoid parse errors.
I did as you said here. I made the changes you described however using tinker again after cleaning the cache and config.I still get null when i try to log a message but in the sotrage/logs/laravel.log I see the log messages
It looks like you've successfully resolved the issue with logging messages in Laravel. The fact that you're seeing the log messages in storage/logs/laravel.log
confirms that the Log::info()
method is working as expected. The null
you see in Tinker after executing Log::info('this is a log message.');
is normal and not indicative of a problem. In Laravel Tinker, when you execute a command or call a method that doesn't return a value (or returns null
), Tinker will display null
. This behavior is by design and is simply Tinker's way of indicating that the command was executed without a return value.
Here is what's happening:
Logging Works: Your log messages are correctly written to the log file, which means the logging system is configured and working as expected.
Tinker's Output: When you use Log::info()
, it doesn't return a value (or more accurately, it returns null
), which is why Tinker displays null
. This doesn't mean the logging failed; it's just how Tinker represents the absence of a return value.
Logging is Functional: You can confidently use Laravel's logging features in your application. The presence of log entries in storage/logs/laravel.log
is proof of successful logging.
Understanding Tinker Output: Remember that null
in Tinker's output doesn't necessarily indicate an error; it often just means a command didn't return a value. This is expected behavior for many methods, including logging.
well I now learned something new today. I am avaliable. if you are free I could give you access to my discord server where you can help me get to the bottom of the problem. here is an invite : https://discord.gg/3w3qZByu
I made a break through in sucessfully connecting the laravel app to the database on compute engine . I can query the db from the app . so it is a sign that it is connected . however I still get the same issues after adding the dd("hello from login controller");
i did not get result it just went to
The requested URL was not found on this server.
Apache/2.4.52 (Ubuntu) Server at 34.171.170.110 Port 80
i think the issues is related to the routing
Given that you have been able to connect the Laravel application to the database on the Compute Engine and still encountering a "Not Found" error after adding dd("hello from login controller");, it indeed suggests that the issue might be related to routing or the web server configuration rather than the database connection.
Troubleshooting Steps:
Verify Laravel Routes:
routes/web.php
or routes/api.php
.php artisan route:list
command to get a clear list of all registered routes. Make sure your login route is defined correctly.Check Controller Namespace:
Review .htaccess (for Apache):
.htaccess
file in your Laravel's public
directory..htaccess
file (see below).Enable mod_rewrite (Apache):
sudo a2enmod rewrite
.sudo systemctl restart apache2
.Document Root Configuration (Apache):
DocumentRoot
points to your Laravel application's public
directory.<Directory>
block for your project has AllowOverride All
.Clear Laravel Caches:
php artisan config:clear
php artisan route:clear
php artisan cache:clear
Check for Typos:
Example .htaccess
file (Apache):
<IfModule mod_rewrite.c>
<IfModule mod_negotiation.c>
Options -MultiViews -Indexes
</IfModule>
RewriteEngine On
# Redirect Trailing Slashes...
RewriteRule ^(.*)/$ /$1 [L,R=301]
# Handle Front Controller...
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ index.php [L]
</IfModule>
I did all of that and still no luck
/etc/apache2/sites-enabled$ cat 000-default.conf
<VirtualHost *:79>
# The ServerName directive sets the request scheme, hostname and port that
# the server uses to identify itself. This is used when creating
# redirection URLs. In the context of virtual hosts, the ServerName
# specifies what hostname must appear in the request's Host: header to
# match this virtual host. For the default virtual host (this file) this
# value is not decisive as it is used as a last resort host regardless.
# However, you must set it for any further virtual host explicitly.
#ServerName www.example.com
ServerAdmin webmaster@localhost
DocumentRoot /var/www/html/public
<Directory /var/www/html/public>
AllowOverride All
Require all granted
</Directory>
# Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
# error, crit, alert, emerg.
# It is also possible to configure the loglevel for particular
# modules, e.g.
#LogLevel info ssl:warn
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
# For most configuration files from conf-available/, which are
# enabled or disabled at a global level, it is possible to
# include a line for only one particular virtual host. For example the
# following line enables the CGI configuration for this host only
# after it has been globally disabled with "a2disconf".
#Include conf-available/serve-cgi-bin.conf
</VirtualHost>
# vim: syntax=apache ts=4 sw=4 sts=4 sr noet
Based on the configuration you've shared, there are a couple of points that stand out and could potentially be causing the issue:
Your Apache configuration snippet shows <VirtualHost *:79>
, which means Apache is listening on port 79 for this virtual host. This is unusual because HTTP traffic typically runs over port 80 (or port 443 for HTTPS). Unless you have a specific reason for using port 79 and have configured your network and application to use this port, this might be the source of the problem.
Solution: If you intended to use the standard HTTP port, change the VirtualHost directive to listen on port 80:
<VirtualHost *:80>
After making this change, restart Apache to apply the configuration:
sudo systemctl restart apache2
If you're using a non-standard port by design, ensure that your requests to the Laravel application are explicitly targeting port 79 (e.g., http://34.171.170.110:79
). If not, and there's no specific reason to use port 79, switching back to the default port 80 (as mentioned above) is recommended.
Check Apache and Laravel Logs
Apache Logs: Check the Apache error logs (${APACHE_LOG_DIR}/error.log
) for any specific errors that could indicate why the request was not found. The error log might provide more details on what's going wrong.
Laravel Logs: Also, review the Laravel application logs in storage/logs/laravel.log
for any application-specific errors that might not be related to Apache but could cause the routing to fail.
Ensure Apache and PHP are Correctly Configured
PHP Module: Ensure that the PHP module is enabled in Apache. You can check this by running a2enmod php<version>
(replace <version>
with your PHP version, e.g., php7.4
).
Server Restart: Every time you change the Apache configuration or enable a module, remember to restart Apache to apply the changes.
Firewall or Port Blocking
If you're using a non-standard port (like 79), ensure that your server's firewall or any network firewalls (including cloud provider firewalls) are configured to allow traffic on that port.
If the issue persists after verifying the port and ensuring Apache is correctly configured and restarted, consider simplifying the setup to diagnose the problem:
Static HTML File: Temporarily place a simple index.html
file in the /var/www/html/public
directory with basic content (e.g., <h1>Hello World</h1>
) and try accessing it via your browser. This can help confirm whether the issue lies with Apache serving files from the DocumentRoot
or if it's more related to Laravel's routing.
when i change it to 80
i get :
apache error logs
/var/log/apache2$ cat error.log
[Wed Mar 27 00:00:15.522399 2024] [mpm_prefork:notice] [pid 36887] AH00163: Apache/2.4.52 (Ubuntu) configured -- resuming normal operations
[Wed Mar 27 00:00:15.522530 2024] [core:notice] [pid 36887] AH00094: Command line: '/usr/sbin/apache2'
[Wed Mar 27 06:08:17.083345 2024] [php:error] [pid 42882] [client 159.89.171.190:54594] script '/var/www/html/upl.php' not found or unable to stat
[Wed Mar 27 06:08:19.035019 2024] [php:error] [pid 42886] [client 159.89.171.190:54634] script '/var/www/html/1.php' not found or unable to stat
[Wed Mar 27 06:08:20.982714 2024] [php:error] [pid 42883] [client 159.89.171.190:33340] script '/var/www/html/password.php' not found or unable to stat
[Wed Mar 27 06:08:21.468143 2024] [php:error] [pid 42884] [client 159.89.171.190:33350] script '/var/www/html/info.php' not found or unable to stat
[Wed Mar 27 08:27:04.902661 2024] [php:error] [pid 42886] [client 83.97.73.245:48246] script '/var/www/html/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php' not found or unable to stat
[Wed Mar 27 08:32:01.629545 2024] [php:error] [pid 45493] [client 83.97.73.245:40722] script '/var/www/html/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php' not found or unable to stat
[Wed Mar 27 19:38:23.498199 2024] [mpm_prefork:notice] [pid 36887] AH00170: caught SIGWINCH, shutting down gracefully
[Wed Mar 27 19:38:23.673514 2024] [mpm_prefork:notice] [pid 123697] AH00163: Apache/2.4.52 (Ubuntu) configured -- resuming normal operations
[Wed Mar 27 19:38:23.673624 2024] [core:notice] [pid 123697] AH00094: Command line: '/usr/sbin/apache2'
[Wed Mar 27 20:53:17.151001 2024] [mpm_prefork:notice] [pid 123697] AH00170: caught SIGWINCH, shutting down gracefully
[Wed Mar 27 20:53:17.290753 2024] [mpm_prefork:notice] [pid 128178] AH00163: Apache/2.4.52 (Ubuntu) configured -- resuming normal operations
[Wed Mar 27 20:53:17.290872 2024] [core:notice] [pid 128178] AH00094: Command line: '/usr/sbin/apache2'
laravel logs
[stacktrace]
#0 /var/www/html/vendor/laravel/framework/src/Illuminate/Foundation/Console/RouteListCommand.php(234): ReflectionClass->__construct()
#1 /var/www/html/vendor/laravel/framework/src/Illuminate/Foundation/Console/RouteListCommand.php(156): Illuminate\\Foundation\\Console\\RouteListCommand->isVendorRoute()
#2 /var/www/html/vendor/laravel/framework/src/Illuminate/Foundation/Console/RouteListCommand.php(125): Illuminate\\Foundation\\Console\\RouteListCommand->getRouteInformation()
#3 [internal function]: Illuminate\\Foundation\\Console\\RouteListCommand->Illuminate\\Foundation\\Console\\{closure}()
#4 /var/www/html/vendor/laravel/framework/src/Illuminate/Collections/Arr.php(560): array_map()
#5 /var/www/html/vendor/laravel/framework/src/Illuminate/Collections/Collection.php(768): Illuminate\\Support\\Arr::map()
#6 /var/www/html/vendor/laravel/framework/src/Illuminate/Foundation/Console/RouteListCommand.php(124): Illuminate\\Support\\Collection->map()
#7 /var/www/html/vendor/laravel/framework/src/Illuminate/Foundation/Console/RouteListCommand.php(110): Illuminate\\Foundation\\Console\\RouteListCommand->getRoutes()
#8 /var/www/html/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(36): Illuminate\\Foundation\\Console\\RouteListCommand->handle()
#9 /var/www/html/vendor/laravel/framework/src/Illuminate/Container/Util.php(41): Illuminate\\Container\\BoundMethod::Illuminate\\Container\\{closure}()
#10 /var/www/html/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(93): Illuminate\\Container\\Util::unwrapIfClosure()
#11 /var/www/html/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(35): Illuminate\\Container\\BoundMethod::callBoundMethod()
#12 /var/www/html/vendor/laravel/framework/src/Illuminate/Container/Container.php(661): Illuminate\\Container\\BoundMethod::call()
#13 /var/www/html/vendor/laravel/framework/src/Illuminate/Console/Command.php(183): Illuminate\\Container\\Container->call()
#14 /var/www/html/vendor/symfony/console/Command/Command.php(326): Illuminate\\Console\\Command->execute()
#15 /var/www/html/vendor/laravel/framework/src/Illuminate/Console/Command.php(152): Symfony\\Component\\Console\\Command\\Command->run()
#16 /var/www/html/vendor/symfony/console/Application.php(1078): Illuminate\\Console\\Command->run()
#17 /var/www/html/vendor/symfony/console/Application.php(324): Symfony\\Component\\Console\\Application->doRunCommand()
#18 /var/www/html/vendor/symfony/console/Application.php(175): Symfony\\Component\\Console\\Application->doRun()
#19 /var/www/html/vendor/laravel/framework/src/Illuminate/Console/Application.php(102): Symfony\\Component\\Console\\Application->run()
#20 /var/www/html/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(155): Illuminate\\Console\\Application->run()
#21 /var/www/html/artisan(35): Illuminate\\Foundation\\Console\\Kernel->handle()
#22 {main}
"}
wait I think I got it to work cause i placed a dd() in the login controller and I saw it responed
If you are not able to clear the cache of the application from command line, then you can also delete this cache files and folders manually, for this you follow the guide:(URL Removed by Staff)