Shopware 6 Cronjob Challenges: Resolving 'MySQL Server Has Gone Away' and Overdue Tasks

Shopware 6 Cronjob Challenges: Resolving 'MySQL Server Has Gone Away' and Overdue Tasks

Managing background processes efficiently is crucial for Shopware 6 store performance. Many merchants and developers opt to move Shopware's scheduled tasks and message queue processing to cronjobs to offload the web server and ensure consistent execution. However, this process can sometimes lead to unexpected errors and tasks piling up, as highlighted in a recent forum discussion.

The Problem: MySQL Disconnections and Overdue Tasks

A Shopware 6.7.8.2 user, running PHP 8.2, encountered a critical issue after configuring cronjobs for scheduled-task:run and messenger:consume. The primary error observed was:

SQLSTATE[HY000]: General error: 2006 MySQL server has gone away

This error occurred during the execution of scheduled-task:run. Concurrently, FroshTools reported significant backlogs: "Open Queues - 148min" and "Scheduled Tasks Overdue - 35min". The initial cronjob commands were:

/opt/plesk/php/8.2/bin/php -d memory_limit=512M /var/www/vhosts/mypage/httpdocs/testshop2/bin/console scheduled-task:run

/opt/plesk/php/8.2/bin/php -d memory_limit=512M /var/www/vhosts/mypage/httpdocs/testshop2/bin/console messenger:consume async --time-limit=295 --memory-limit=512M

Initial Troubleshooting and Insights

Community members quickly weighed in with advice. One suggestion was to add a --time-limit parameter to the scheduled-task:run command, for example:

scheduled-task:run --time-limit=10

While executing this command via console resulted in "Scheduled task runner stopped due to time limit of 10s reached," it didn't directly resolve the underlying MySQL disconnection. This indicated the task runner was working, but either the time limit was too short for the workload, or another issue was preventing full completion.

A crucial insight from the discussion pointed to the "MySQL server has gone away" error itself. This error typically signifies that the database server closed the connection unexpectedly, often due to resource limitations or a query exceeding server-side limits (like wait_timeout or max_allowed_packet). The advice was to investigate the DB server's health and logs.

The Solution for 'MySQL Server Has Gone Away'

The original poster later confirmed a significant breakthrough: the "MySQL server has gone away" problem was (they believed) resolved by increasing the max_allowed_packet size in the MySQL configuration file (my.cnf) to 1G:

max_allowed_packet = 1G

This setting determines the maximum size of a single packet or any generated/intermediate string, or any parameter sent by the MySQL client or received by the MySQL server. Increasing it often helps with large data transfers or complex queries that might otherwise cause the server to drop the connection.

Addressing Persistent Overdue Tasks and Queue Management

Even after fixing the MySQL connection issue, the user still observed that the task load in FroshTools wasn't decreasing, despite both cronjobs running every 5 minutes. This led to further discussion on robust queue management:

• Consistent Parameters: It was emphasized that both cronjobs, especially scheduled-task:run, should always be called with parameters like --time-limit to prevent them from running indefinitely and consuming excessive resources.
• Log Analysis: Checking server logs and Shopware logs for any new error messages is paramount to understanding why tasks aren't being processed.
• Queue Backend: Determine if the message queue is stored in the database or utilizing a dedicated service like Redis. Checking the respective storage for entries can reveal if messages are accumulating or failing to process.
• Resetting Queues: If a large backlog has accumulated, FroshTools offers options to reset the queue and re-register tasks, which can be a useful step to clear a stalled queue.
• Supervisor for Robustness: A key recommendation for production environments is to use a process manager like Supervisor instead of simple cronjobs for messenger:consume. Supervisor ensures that the consumer process is always running and automatically restarts it if it fails, providing a more reliable and persistent way to process messages. While not directly solving the initial MySQL error, it's a best practice for long-term queue stability.
• PHP Version: A general recommendation was made to consider upgrading to newer PHP versions (e.g., 8.4 or 8.5), as PHP 8.2 will only receive security updates until the end of 2026. While not a direct fix for the cronjob issue, it's good for performance and future compatibility.

Key Takeaways for Shopware 6 Users

This forum topic provides valuable insights for anyone struggling with Shopware 6 cronjobs and background task processing:

• The "MySQL server has gone away" error in Shopware cronjobs can often be resolved by increasing max_allowed_packet in my.cnf.
• Always use appropriate --time-limit and --memory-limit parameters for Shopware console commands in cronjobs.
• Thoroughly check logs (Shopware and server) for underlying issues.
• For robust and continuous message queue processing, consider using a process manager like Supervisor instead of standard cronjobs.
• Regularly monitor FroshTools for queue and scheduled task status to catch issues early.