6amMart Server Issue — Diagnosis & Fix Summary

  1. Overview
  2. Errors & Fixes
  3. 6amMart Server Issue — Diagnosis & Fix Summary

Date: September 6, 2026
Server: DigitalOcean Droplet (139.59.45.53) — Ubuntu 22.04, 2 vCPU, 3.82GB RAM, aaPanel
Domain affected: admin.mydearcart.com

Problem

Random "500 Internal Server Error" on the Laravel admin panel, intermittently, over several days.

Root Cause Found

  1. Laravel logs showed a PDOException: SQLSTATE[HY000] [2002] No such file or directory — meaning Laravel couldn't reach MySQL because MySQL's socket file was missing.

  2. MySQL's own error log (/www/server/data/ubuntu-s-2vcpu-4gb-blr1-01.err) showed repeated "Database was not shutdown normally!" messages — 35+ occurrences between Sep 2–6.

  3. journalctl -k confirmed the real cause: the Linux kernel's OOM (Out-Of-Memory) Killer was repeatedly killing the mysqld process because the server ran out of available RAM. This happened 15+ times in 4 days, sometimes multiple times within minutes of each other.

  4. free -h confirmed the server had 0B of swap space — so the moment RAM filled up, the kernel had no fallback and had to kill a process immediately (MySQL, being memory-heavy, was usually the victim).

Contributing Factor

The 3.82GB RAM server is running many services simultaneously: MySQL, PHP-FPM (Laravel), a mail server (rspamd), a Node.js app via pm2, aaPanel itself (btpanel), and the web server (httpd) — all competing for limited memory.

Fix Applied (today)

Added a 2GB swap file as a memory safety buffer:

fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab
sysctl vm.swappiness=10
echo 'vm.swappiness=10' >> /etc/sysctl.conf

Confirmed active: free -h now shows Swap: 2.0Gi.

Effect: This should significantly reduce (not fully eliminate) sudden MySQL crashes and the resulting 500 errors, since the kernel now has breathing room before it needs to kill a process.

Still Recommended (not yet done — for future action)

Priority

Action

Why

High

Monitor for further OOM kills: journalctl -k --no-pager | grep -i "oom-kill" | tail -5

Confirm swap actually reduced crash frequency

High

Move mail server (rspamd) off this box, or switch to a third-party service like Mailgun/SendGrid

Frees significant RAM

Medium

Review what the pm2/Node.js app is for and whether it's essential on this server

Minor RAM user currently (37MB) but worth confirming

Medium

Tune innodb_buffer_pool_size in MySQL config (currently 256M) if RAM stays tight

Reduces MySQL's own memory footprint

High (longer term)

Upgrade the DigitalOcean Droplet to 8GB RAM as order volume grows

4GB is undersized for MySQL + Laravel + mail + Node + panel together, especially at peak traffic

Useful commands for next time

  • Check Laravel error: tail -100 /www/wwwroot/admin.mydearcart.com/storage/logs/laravel.log

  • Check MySQL status: systemctl status mysqld

  • Check MySQL's own error log: tail -200 /www/server/data/ubuntu-s-2vcpu-4gb-blr1-01.err

  • Check for OOM kills: journalctl -k --no-pager | grep -i "oom-kill"

  • Check memory/swap: free -h

Keep an eye on the site over the next few days — if 500 errors return, check journalctl -k | grep oom-kill first to see if it's the same memory issue recurring despite swap, which would be the signal to move forward with the RAM upgrade or offloading the mail server.

Was this article helpful?