Troubleshooting
If you encounter issues with PteroCA, gathering and reviewing error logs is often the first step to diagnosing the problem. Below are some common troubleshooting techniques to help you identify and resolve issues in your Symfony project.
Installation errors
Errors during creating Pterodactyl Account
Error while connecting to the Pterodactyl API
If you see this error, PteroCA is unable to communicate with Pterodactyl via API. In this case, please ensure that the API Key and Pterodactyl URL are correct.
This action is unauthorized
If you see this error, it means that the API key you created in Pterodactyl does not have sufficient permissions.
You need to create a new API key with the correct permissions and update it accordingly.
The resource you are looking for could not be found
If you see this error, it is most likely because you do not have the PteroCA plugin for Pterodactyl installed.
Follow the instructions to install the PteroCA plugin for Pterodactyl here: 🔗 Install PteroCA Plugin
Learn more about the PteroCA plugin here: 🔗 PteroCA Pterodactyl Addon
Permission Denied Errors
If you encounter errors related to file permissions, especially for logs or cache, it's likely that your web server user (e.g., www-data) does not have the correct permissions to write to the necessary directories.
Solution: Adjust the permissions of the var/log and var/cache directories to ensure they are writable by the web server:
sudo chown -R www-data:www-data var/log var/cache
sudo chmod -R 775 var/log var/cacheCommon issues and Solutions
500 Internal Server Errors
A generic 500 error can occur for many reasons, such as a misconfigured server, a critical PHP error, or an uncaught exception.
Check the log files (
prod.logordev.loginvar/log/directory) for more detailed error messages. Look for PHP fatal errors, uncaught exceptions, or missing configurations that might be causing the issue.If no logs appear, ensure that folder permissions are correctly set (see this section below).
If this does not help, modify the
.envfile by changing theAPP_ENVline to development mode:
APP_ENV=devAfter refreshing the page with the 500 error, you should see a detailed exception message explaining the issue.
If you changed APP_ENV to dev for debugging purposes, make sure to switch it back to prod (APP_ENV=prod) after resolving the issue to maintain security and performance in the production environment.
Database connection issues
If your application is unable to connect to the database, it's likely due to incorrect credentials or configuration. Follow these steps to troubleshoot:
Check
.envConfiguration: Verify that theDATABASE_URLin your.envfile is correct.Log Output: Review the logs in
var/log/prod.log(ordev.log) for any database-related errors such as connection timeouts or authentication failures.Example fix:
DATABASE_URL=mysql://db_user:[email protected]:3306/db_name
Missing or outdated dependencies
Your Symfony application may fail to function correctly if some of its required dependencies are missing or outdated. This can cause issues such as class not found errors or service failures.
Solution: Run the following command to install or update the necessary dependencies:
composer installor
composer updateMake sure your
vendor/directory is populated with all required libraries.
Twig template errors
Issues with your Twig templates, such as incorrect syntax or missing variables, can cause runtime errors when rendering views.
Solution: Review the error messages in your logs, which should indicate the problematic template file and line number. Fix the syntax or pass the correct variables to the templates.
Accessing error logs
Symfony logs all errors and important events to log files, which are stored in the var/log directory. These logs can provide valuable insight into what went wrong and help you debug the issue effectively.
Viewing recent logs
To check recent log entries, you can use the following command to display the last 100 lines of the log file directly in your terminal:
tail -n 100 var/log/prod.logIf you are running your application in a development environment, use the dev.log instead:
tail -n 100 var/log/dev.logThis will output the most recent log entries, which may contain error messages, warnings, or other details that can help pinpoint the issue.
Monitoring logs in real time
If you want to actively monitor your logs while you work on debugging, you can use the -f flag with the tail command. This will continuously display new log entries as they are written to the log file:
tail -f var/log/prod.logFor development logs:
tail -f var/log/dev.logThis is particularly useful when you are testing fixes or changes and want to see immediate feedback on how the system is responding.
Resetting logs
If you want to clear the log file to start fresh while debugging, you can truncate the log file with the following command:
> var/log/prod.logThis will empty the log file, making it easier to identify new issues after you've applied fixes.
Last updated