MySQL/Wordpress issue
-
@wls-itguy said in MySQL/Wordpress issue:
@jmoore said in MySQL/Wordpress issue:
Have you changed any permissions or config files recently?
I had some issues with wordpress updating and had done some permission changes to wordpress files
Try shutting down Apache. THEN bring up MySQL. Let's see if MySQL dies when nothing is touching it.
-
If MySQL dies when Apache is offline, then we can rule out issues with Apache or WordPress as being the problem. I'm assuming this is a pure MySQL issue, but want to be sure.
-
@scottalanmiller said in MySQL/Wordpress issue:
@wls-itguy said in MySQL/Wordpress issue:
@scottalanmiller said in MySQL/Wordpress issue:
@wls-itguy said in MySQL/Wordpress issue:
@scottalanmiller said in MySQL/Wordpress issue:
Are you just running a single WordPress site here?
Yes. Single site.
Given that the site is now down... is there a good reason that you are running a WP site on your own instead of through a server (asks the guy who runs a service for that.)
It has been 2+ years since it has been set up this way. Wasn't broken, why fix it.
Someone had to set it up that way to start with
and...
http://www.smbitjournal.com/2017/07/if-it-aint-broke-dont-fix-it/
What I meant by my statement was that it has been working. We didn't see a need to move it off a host to a wordpress specific site. I update it regularly but wasn't ready to upgrade to a new version of Debian at this time.
-
@scottalanmiller said in MySQL/Wordpress issue:
@wls-itguy said in MySQL/Wordpress issue:
@jmoore said in MySQL/Wordpress issue:
Have you changed any permissions or config files recently?
I had some issues with wordpress updating and had done some permission changes to wordpress files
Try shutting down Apache. THEN bring up MySQL. Let's see if MySQL dies when nothing is touching it.
@scottalanmiller said in MySQL/Wordpress issue:
If MySQL dies when Apache is offline, then we can rule out issues with Apache or WordPress as being the problem. I'm assuming this is a pure MySQL issue, but want to be sure.
So far it is still running:
root@www:~# mysqladmin -u root -p status
Enter password:
Uptime: 147 Threads: 1 Questions: 198 Slow queries: 0 Opens: 97 Flush tables: 1 Open tables: 90 Queries per second avg: 1.346 -
now what do you get from [service mysql status] ?
-
@jmoore said in MySQL/Wordpress issue:
now what do you get from [service mysql status] ?
root@www:~# service mysql status
[info] /usr/bin/mysqladmin Ver 8.42 Distrib 5.5.55, for debian-linux-gnu on x86_64
Copyright (c) 2000, 2017, Oracle and/or its affiliates. All rights reserved.Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.Server version 5.5.55-0+deb7u1
Protocol version 10
Connection Localhost via UNIX socket
UNIX socket /var/run/mysqld/mysqld.sock
Uptime: 5 min 46 secThreads: 1 Questions: 202 Slow queries: 0 Opens: 97 Flush tables: 1 Open tables: 90 Queries per second avg: 0.583.
-
Well I think things are looking up. That was a good idea from Scott to shut down Apache and then work with mysql. I think you can go ahead and start Apache back up and let those run for a while to see what happens.
-
As soon as I start Apache2 MySQL stops working.
-
@wls-itguy Well thats a bummer. What does your apache error log say when that happens?
-
Okay, there is a really good chance that we have a WordPress issue here. I think that rolling back to before the last update might be the logical place to start.
-
@scottalanmiller said in MySQL/Wordpress issue:
Okay, there is a really good chance that we have a WordPress issue here. I think that rolling back to before the last update might be the logical place to start.
Any bets on a compromised plugin causing issues?
-
@scottalanmiller said in MySQL/Wordpress issue:
Okay, there is a really good chance that we have a WordPress issue here. I think that rolling back to before the last update might be the logical place to start.
If you want to isolate to WP (thought I cannot see how it is anything else), I would shut down apache,
mvyour WP directory elsewhere and start apache back up. -
@jaredbusch said in MySQL/Wordpress issue:
@scottalanmiller said in MySQL/Wordpress issue:
Okay, there is a really good chance that we have a WordPress issue here. I think that rolling back to before the last update might be the logical place to start.
If you want to isolate to WP (thought I cannot see how it is anything else), I would shut down apache,
mvyour WP directory elsewhere and start apache back up.True, but in theory it is the only thing running on Apache. So likely it was isolated in the last test, unless the other info wasn't correct.
-
@scottalanmiller said in MySQL/Wordpress issue:
@jaredbusch said in MySQL/Wordpress issue:
@scottalanmiller said in MySQL/Wordpress issue:
Okay, there is a really good chance that we have a WordPress issue here. I think that rolling back to before the last update might be the logical place to start.
If you want to isolate to WP (thought I cannot see how it is anything else), I would shut down apache,
mvyour WP directory elsewhere and start apache back up.True, but in theory it is the only thing running on Apache. So likely it was isolated in the last test, unless the other info wasn't correct.
Correct, but because of possible compromise issues, or just something he does not know about because he did not set it up, there is always a chance.
I do agree it will probably not come back showing anything but WP to be the issue.
-
I would check the Apache logs before rolling back as well.
Has the server been completely restarted? (I've followed the thread and haven't seen any mention of that.)
-
@jaredbusch said in MySQL/Wordpress issue:
@scottalanmiller said in MySQL/Wordpress issue:
@jaredbusch said in MySQL/Wordpress issue:
@scottalanmiller said in MySQL/Wordpress issue:
Okay, there is a really good chance that we have a WordPress issue here. I think that rolling back to before the last update might be the logical place to start.
If you want to isolate to WP (thought I cannot see how it is anything else), I would shut down apache,
mvyour WP directory elsewhere and start apache back up.True, but in theory it is the only thing running on Apache. So likely it was isolated in the last test, unless the other info wasn't correct.
Correct, but because of possible compromise issues, or just something he does not know about because he did not set it up, there is always a chance.
I do agree it will probably not come back showing anything but WP to be the issue.
How about disabling plugins?
-
@dafyre said in MySQL/Wordpress issue:
I would check the Apache logs before rolling back as well.
Has the server been completely restarted? (I've followed the thread and haven't seen any mention of that.)
Yes. A few times
-
What's do the Apache logs look like?
(most likely in /var/log/apache2/apache.log and error.log)
-
@dafyre said in MySQL/Wordpress issue:
What's do the Apache logs look like?
(most likely in /var/log/apache2/apache.log and error.log)
There isn't an apache.logError Log:
[Sun Jul 16 06:25:01 2017] [notice] Apache/2.2.22 (Debian) PHP/5.4.45-0+deb7u8 mod_ssl/2.2.22 OpenSSL/1.0.1t configured -- resuming normal operations
[Sun Jul 16 21:18:24 2017] [notice] caught SIGTERM, shutting down
[Sun Jul 16 21:19:16 2017] [notice] Apache/2.2.22 (Debian) PHP/5.4.45-0+deb7u8 mod_ssl/2.2.22 OpenSSL/1.0.1t configured -- resuming normal operations
[Tue Jul 18 11:32:30 2017] [error] an unknown filter was not added: includes
[Tue Jul 18 11:33:04 2017] [error] an unknown filter was not added: includes
[Tue Jul 18 11:33:17 2017] [error] an unknown filter was not added: includes
[Tue Jul 18 14:34:00 2017] [error] an unknown filter was not added: includes
[Tue Jul 18 14:34:00 2017] [error] an unknown filter was not added: includes
[Tue Jul 18 14:34:23 2017] [error] an unknown filter was not added: includes
[Thu Jul 20 09:27:41 2017] [notice] caught SIGTERM, shutting down
[Thu Jul 20 09:28:00 2017] [notice] Apache/2.2.22 (Debian) PHP/5.4.45-0+deb7u8 mod_ssl/2.2.22 OpenSSL/1.0.1t configured -- resuming normal operations
[Fri Jul 21 09:09:13 2017] [notice] caught SIGTERM, shutting down
[Fri Jul 21 09:10:28 2017] [notice] Apache/2.2.22 (Debian) PHP/5.4.45-0+deb7u8 mod_ssl/2.2.22 OpenSSL/1.0.1t configured -- resuming normal operations
[Fri Jul 21 09:11:40 2017] [error] server reached MaxClients setting, consider raising the MaxClients setting
[Fri Jul 21 12:46:22 2017] [notice] caught SIGTERM, shutting down
[Fri Jul 21 12:47:13 2017] [notice] Apache/2.2.22 (Debian) PHP/5.4.45-0+deb7u8 mod_ssl/2.2.22 OpenSSL/1.0.1t configured -- resuming normal operations
[Fri Jul 21 12:48:16 2017] [error] server reached MaxClients setting, consider raising the MaxClients setting
[Fri Jul 21 13:40:23 2017] [notice] caught SIGTERM, shutting down
[Fri Jul 21 13:49:21 2017] [notice] Apache/2.2.22 (Debian) PHP/5.4.45-0+deb7u8 mod_ssl/2.2.22 OpenSSL/1.0.1t configured -- resuming normal operations
[Fri Jul 21 13:50:59 2017] [notice] caught SIGTERM, shutting down -
From my earlier post it still looks like you are getting spammed.
This: [Fri Jul 21 09:11:40 2017] [error] server reached MaxClients setting, consider raising the MaxClients setting
says that to me. In your Apache2.conf file you can adjust that using an editor then restart Apache. Since you are on Linode you will find this useful, tuning apache.
