Help solving following error: #2002 - No such file or directory<br />

July 24, 2018 248 views
MySQL PHP Ubuntu 16.04

I've searched around the internet for quite some time but have been unable to come up with a working solution. I have a WordPress site set up on a Ubuntu 16.04 LAMP running MySQL. My WP site isn't working properly (E.g. returning with the "Error establishing a database connection" message when attempting to visit my /wp-admin/ page). I also get the following error when attempting to log into phpMyAdmin: #2002 - No such file or directory<br />The server is not responding (or the local server's socket is not correctly configured).

Here are the printed results when running systemctl status mysql.service:

● mysql.service - MySQL Community Server
   Loaded: loaded (/lib/systemd/system/mysql.service; enabled; vendor preset: enabled)
   Active: activating (start-post) (Result: exit-code) since Tue 2018-07-24 17:56:44 UTC; 6s ago
  Process: 13857 ExecStart=/usr/sbin/mysqld (code=exited, status=2)
  Process: 13847 ExecStartPre=/usr/share/mysql/mysql-systemd-start pre (code=exited, status=0/SUCCESS)
 Main PID: 13857 (code=exited, status=2);         : 13858 (mysql-systemd-s)
    Tasks: 2
   Memory: 356.0K
      CPU: 318ms
   CGroup: /system.slice/mysql.service
           └─control
             ├─13858 /bin/bash /usr/share/mysql/mysql-systemd-start post
             └─13886 sleep 1

Jul 24 17:56:44 bcmg-lamp-16-04 systemd[1]: Stopped MySQL Community Server.
Jul 24 17:56:44 bcmg-lamp-16-04 systemd[1]: Starting MySQL Community Server...
Jul 24 17:56:45 bcmg-lamp-16-04 systemd[1]: mysql.service: Main process exited, code=exited, status=2/INVALIDARGUMENT

And here are the printed results when running journalctl -xe:

Jul 24 17:57:14 bcmg-lamp-16-04 systemd[1]: mysql.service: Unit entered failed state.
Jul 24 17:57:14 bcmg-lamp-16-04 systemd[1]: mysql.service: Failed with result 'exit-code'.
Jul 24 17:57:15 bcmg-lamp-16-04 systemd[1]: mysql.service: Service hold-off time over, scheduling restart.
Jul 24 17:57:15 bcmg-lamp-16-04 systemd[1]: Stopped MySQL Community Server.
-- Subject: Unit mysql.service has finished shutting down
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit mysql.service has finished shutting down.
Jul 24 17:57:15 bcmg-lamp-16-04 systemd[1]: Starting MySQL Community Server...
-- Subject: Unit mysql.service has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit mysql.service has begun starting up.
Jul 24 17:57:15 bcmg-lamp-16-04 audit[13947]: AVC apparmor="DENIED" operation="open" profile="/usr/sbin/mysqld" name="/proc/13947/status" pid=13947 comm="mysqld" requested_mask="r" denied_
Jul 24 17:57:15 bcmg-lamp-16-04 kernel: audit: type=1400 audit(1532455035.251:67360): apparmor="DENIED" operation="open" profile="/usr/sbin/mysqld" name="/proc/13947/status" pid=13947 comm
Jul 24 17:57:15 bcmg-lamp-16-04 audit[13947]: AVC apparmor="DENIED" operation="open" profile="/usr/sbin/mysqld" name="/sys/devices/system/node/" pid=13947 comm="mysqld" requested_mask="r" 
Jul 24 17:57:15 bcmg-lamp-16-04 audit[13947]: AVC apparmor="DENIED" operation="open" profile="/usr/sbin/mysqld" name="/proc/13947/status" pid=13947 comm="mysqld" requested_mask="r" denied_
Jul 24 17:57:15 bcmg-lamp-16-04 kernel: audit: type=1400 audit(1532455035.255:67361): apparmor="DENIED" operation="open" profile="/usr/sbin/mysqld" name="/sys/devices/system/node/" pid=139
Jul 24 17:57:15 bcmg-lamp-16-04 kernel: audit: type=1400 audit(1532455035.255:67362): apparmor="DENIED" operation="open" profile="/usr/sbin/mysqld" name="/proc/13947/status" pid=13947 comm
Jul 24 17:57:15 bcmg-lamp-16-04 systemd[1]: mysql.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
Jul 24 17:57:24 bcmg-lamp-16-04 sshd[13984]: Received disconnect from 13.56.116.93 port 48842:11: Normal Shutdown, Thank you for playing [preauth]
Jul 24 17:57:24 bcmg-lamp-16-04 sshd[13984]: Disconnected from 13.56.116.93 port 48842 [preauth]
2 Answers

Hello friend!

I'm sorry about the trouble you're having here. Let's ignore the phpMyAdmin thing, it's a rabbit hole that won't solve the underlying issue. What you are dealing with is something that so many people deal with who run their own servers. In fact, if you search for the error you will find people everywhere talking about dealing with it for the first time in mass quantities. This to say, MySQL crashes are not at all uncommon. The most common reason for this is the system running out of memory. The quickest short term fix is to log in via SSH or the web console and run “service mysql restart” (“mysqld” for CentOS/Fedora).

There are a few ways to resolve this problem to prevent this from happening again.

1) Resize to a larger droplet (don't do this until you've read the rest). If you are running a full web stack with MySQL, we recommend at least 1GB of memory. However, larger applications may need much more than that, it is very relative to your application.

https://www.digitalocean.com/community/tutorials/how-to-resize-your-droplets-on-digitalocean

2) Optimize your MySQL configuration. A great tool for this is MySQLtuner (http://mysqltuner.com). Note that the longer your server has been running before using this, the more accurate its suggestions will be. These settings are adjusted in /etc/my.cnf.

You can get an example of the memory usage from your current or proposed settings with this calculator:
http://www.mysqlcalculator.com

3) Reduce your web application’s reliance on MySQL for page loads. This can usually be done by adding static caching to your application. For example, Joomla has caching as a built in feature that can be enabled. Another example, Wordpress can use plugins (like WP Super Cache) to add in this kind of functionality.

Take note that upgrading the droplet is an option, but hardly the one I recommend. Number 3 in my list there is key. The thing about Wordpress is that a 1GB droplet might house one Wordpress site well, and for someone else a 64GB droplet might fail to house their website well. This is why you have to be careful with just upgrading the droplet. I don't want you to pay more only to find that it doesn't help you. I only want you to do that if it truly ends up being the only option. The reason droplet size may not have a significant impact is that plugins and themes are capable of driving Wordpress resource needs through the roof. Raising the ceiling seems like the right reaction, but if the problem is bad enough then the problem will simply scale up to the new ceiling and hit the same problem. These are my go to rules for optimizing Wordpress:

  1. Remove all unnecessary plugins. Disabled is not the same as removed.
  2. Remove all unused themes.
  3. Install static caching. Try using WP Super Cache for this.

Keep in mind that some plugins and themes can render static caching ineffective, and in such cases the only thing that you can really do is try to find out which is the cause and consider an alternate solution.

Kind Regards,
Jarland

by Melissa Anderson
Resizing your servers can be an effective way of increasing their capacity, by allowing them to utilize more memory (RAM), CPU, and disk storage. The ability to resize a server, also known as vertical scaling, can be useful in a variety of situations that prompt the need for a more powerful server, such as if your concurrent user base increases or if you need to store more data. In this tutorial, we will show you how to resize your server, also known as a droplet, on DigitalOcean.

Thank you for taking the time to respond to my question. I added a swap as instructed in this tutorial. I've restarted MySQL using the following command: service mysql restart. I've powered my droplet off then back on again. I checked the memory usage with the df -h command and am receiving the following results:

Filesystem      Size  Used Avail Use% Mounted on
udev            487M     0  487M   0% /dev
tmpfs           100M  3.1M   97M   4% /run
/dev/vda1        29G  3.9G   26G  14% /
tmpfs           497M     0  497M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           497M     0  497M   0% /sys/fs/cgroup
/dev/vda15      105M  3.4M  102M   4% /boot/efi
tmpfs           100M     0  100M   0% /run/user/1000

Additionally, the site was regularly updated and was cached with WP Rocket, a premium caching plugin which yields much better results with less chance of conflict when compared to WP Super Cache and W3 Total Cache.

I'm not convinced this is a memory issue as you've suggested, though I'm more than willing to admit I'm not certain one way or the other... I'm still new to server management. Thanks again for your help!

by Justin Ellingwood
One of the easiest way of increasing the responsiveness of your server and guarding against out of memory errors in your applications is to add some swap space. In this guide, we will cover how to add a swap file to an Ubuntu 16.04 server. &lt;$&gt;[warning] [label...
Have another answer? Share your knowledge.