Laravel Queue Workers Crashing on cPanel VPS: Why MySQL Timeouts and File‑Permission Errors Kill Your Cron Jobs—and How to Fix It Fast
If you’ve ever watched a Laravel queue grind to a halt on a cPanel VPS, feeling the heat of endless MySQL server has gone away warnings and “Permission denied” errors, you know the frustration is real. One mis‑configured cron job can take down a whole payment pipeline, spam your logs, and waste precious developer hours. This guide cuts through the noise, shows you exactly why those timeouts and permission problems happen, and gives you an actionable, production‑ready fix that gets your workers humming again in minutes.
Why This Matters
Queue workers are the backbone of any Laravel‑powered SaaS, handling email dispatch, video encoding, invoice generation, and API throttling. When they crash:
- Revenue drops because invoices never get sent.
- Customer experience suffers—emails land in spam or never arrive.
- Server resources get wasted on zombie processes, inflating your VPS bill.
In short, a broken queue equals a broken business.
Common Causes on cPanel VPS
1. MySQL Connection Timeouts
cPanel’s default wait_timeout is often set to 60 seconds. Laravel’s queue:work can run long‑running jobs that exceed this limit, causing MySQL to drop the connection mid‑process.
2. File‑Permission Errors
When the queue process runs under the nobody or cpaneluser user, it may lack permission to write to storage/framework/cache or bootstrap/cache. The result is a fatal Permission denied exception that stops the worker.
3. Supervisor Mis‑configuration
Using Supervisor with a cPanel VPS can be tricky. Incorrect numprocs or missing stopwaitsecs values cause workers to be killed by cPanel’s cagefs limits.
Step‑by‑Step Fix Tutorial
Step 1 – Raise MySQL Timeouts
Log into your MySQL console and adjust the session and global variables:
mysql -u root -p
SET GLOBAL wait_timeout = 28800;
SET GLOBAL interactive_timeout = 28800;
-- Optional: persist across restarts
vim /etc/my.cnf
# Add under [mysqld]
wait_timeout=28800
interactive_timeout=28800
Step 2 – Align PHP‑FPM Pool User with Laravel Files
Open your PHP‑FPM pool configuration (usually /etc/php/8.2/fpm/pool.d/www.conf) and set the user/group to match your cPanel account:
; example for user “mycpaneluser”
user = mycpaneluser
group = mycpaneluser
listen.owner = mycpaneluser
listen.group = mycpaneluser
listen.mode = 0660
Reload PHP‑FPM:
systemctl reload php8.2-fpm
Step 3 – Fix Laravel Storage Permissions
storage and bootstrap/cache. Run these commands as the cPanel user:
cd /home/mycpaneluser/public_html/yourapp
chmod -R 775 storage bootstrap/cache
chown -R mycpaneluser:mycpaneluser storage bootstrap/cache
Step 4 – Configure Supervisor Properly
Create (or edit) /etc/supervisor/conf.d/laravel-queue.conf:
[program:laravel-queue]
process_name=%(program_name)s_%(process_num)02d
command=php /home/mycpaneluser/public_html/yourapp/artisan queue:work redis --sleep=3 --tries=3 --timeout=300
autostart=true
autorestart=true
user=mycpaneluser
numprocs=3
redirect_stderr=true
stdout_logfile=/home/mycpaneluser/logs/laravel-queue.log
stopwaitsecs=360
Then update Supervisor:
supervisorctl reread
supervisorctl update
supervisorctl status laravel-queue:*
VPS or Shared Hosting Optimization Tips
- Enable Redis Cache: Install
php-redis, configure.envwithCACHE_DRIVER=redisandQUEUE_CONNECTION=redis. - Use PHP‑FPM over mod_php: Improves concurrency and isolates crashes.
- Turn on OPcache: Add
opcache.enable=1in/etc/php/8.2/fpm/php.ini. - Limit cron frequency: Use
*/5 * * * *for queue:work instead of every minute to reduce load. - Monitor with Netdata or htop: Spot CPU spikes before they kill workers.
Real World Production Example
Acme SaaS runs a Laravel 10 API on a 2 vCPU Ubuntu 22.04 VPS with cPanel. Their original setup crashed every night at 2 AM, logging:
[2023-09-12 02:13:45] production.ERROR: PDOException: SQLSTATE[HY000] [2006] MySQL server has gone away
After applying the steps above, they observed:
- Zero MySQL timeout errors for 30 days.
- Queue latency dropped from 45 seconds to < 2 seconds.
- CPU usage stabilized at 30 % under peak load.
Before vs After Results
| Metric | Before | After |
|---|---|---|
| Queue Failures | 152 / day | 3 / month |
| Avg Job Time | 45 s | 1.8 s |
| CPU Load (peak) | 85 % | 32 % |
Security Considerations
- Never run queue workers as
root. Use the lowest‑privilege cPanel user. - Set
APP_DEBUG=falsein production to avoid leaking stack traces. - Restrict Redis to localhost or a password‑protected instance.
- Enable
fail2banon SSH to prevent brute‑force attacks that could flood your queues.
Bonus Performance Tips
- Enable
queue:restartin your deploy script to gracefully recycle workers. - Compress large payloads before queuing – use
gzcompress()and decompress in the job. - Batch similar jobs with
dispatchNow()when latency is critical.
FAQ
Q: My queue keeps restarting even after fixing permissions. What else could be wrong?
A: Check the cPanelphp.inimax_execution_timeandmemory_limit. If they are too low, Supervisor will think the process died and restart it.
Q: Can I run Laravel queues on a shared hosting plan?
A: Yes, but you must rely on Cron instead of Supervisor and keep job payloads tiny. Consider moving to a low‑cost VPS for production stability.
Final Thoughts
Queue stability is not a “nice‑to‑have”; it’s a revenue‑critical component of any modern PHP SaaS. By aligning MySQL timeouts, file permissions, PHP‑FPM users, and Supervisor settings, you eliminate the most common crash vectors on a cPanel VPS. Pair these fixes with Redis, OPcache, and proper monitoring, and you’ll enjoy a rock‑solid queue pipeline that scales with your business.
No comments:
Post a Comment