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.


Common issues and Solutions

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 .env Configuration: Verify that the DATABASE_URL in your .env file is correct.

  • Log Output: Review the logs in var/log/prod.log (or dev.log) for any database-related errors such as connection timeouts or authentication failures.

    Example fix:

    DATABASE_URL=mysql://db_user:db_password@127.0.0.1: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 install

    or

    composer update

    Make sure your vendor/ directory is populated with all required libraries.

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/cache

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.

  • Solution: Check the log files (prod.log or dev.log) for more detailed error messages. Look for PHP fatal errors, uncaught exceptions, or missing configurations that might be causing the issue.

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.

By staying aware of these common issues and checking your logs regularly, you can often resolve problems quickly and get your Symfony application running smoothly again.


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.log

If you are running your application in a development environment, use the dev.log instead:

tail -n 100 var/log/dev.log

This 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.log

For development logs:

tail -f var/log/dev.log

This 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.log

This will empty the log file, making it easier to identify new issues after you've applied fixes.

Last updated