0

It's pretty much in the title. I've tried everything I can think of but Apache2 is doing a restart every 1min and 3seconds - without fail. It's not doing a graceful restart, as every time it restarts the client can not connect, and are met with "This site can't be reached" in Chrome.

This is happening on a VPS hosted on Linode with the Ubuntu 16.04 image. As far as I know everything was setup as default. (I inherited the site, but trying to figure out this odd issue. )

Apache is version 2.4.18.

PHP is version 7.0.30

The site does not see a lot of traffic (maybe 1k hits/month) - so traffic should not be causing this either.

Below are the logs that I'm seeing from the Apache2 error.log

[Mon Aug 27 23:04:56.015029 2018] [core:notice] [pid 32672] AH00094: Command line: '/usr/sbin/apache2'
[Mon Aug 27 23:05:56.492903 2018] [mpm_prefork:notice] [pid 32672] AH00169: caught SIGTERM, shutting down
[Mon Aug 27 23:05:58.000463 2018] [:notice] [pid 32730] ModSecurity for Apache/2.9.0 (http://www.modsecurity.org/) configured.
[Mon Aug 27 23:05:58.001156 2018] [:notice] [pid 32730] ModSecurity: APR compiled version="1.5.1"; loaded version="1.5.2"
[Mon Aug 27 23:05:58.001857 2018] [:warn] [pid 32730] ModSecurity: Loaded APR do not match with compiled!
[Mon Aug 27 23:05:58.001959 2018] [:notice] [pid 32730] ModSecurity: PCRE compiled version="8.35 "; loaded version="8.38 2015-11-23"
[Mon Aug 27 23:05:58.002041 2018] [:warn] [pid 32730] ModSecurity: Loaded PCRE do not match with compiled!
[Mon Aug 27 23:05:58.002155 2018] [:notice] [pid 32730] ModSecurity: LUA compiled version="Lua 5.1"
[Mon Aug 27 23:05:58.002230 2018] [:notice] [pid 32730] ModSecurity: YAJL compiled version="2.1.0"
[Mon Aug 27 23:05:58.002300 2018] [:notice] [pid 32730] ModSecurity: LIBXML compiled version="2.9.2"
[Mon Aug 27 23:05:58.002460 2018] [:notice] [pid 32730] ModSecurity: StatusEngine call: "2.9.0,Apache/2.4.18 (Ubuntu),1.5.1/1.5.2,8.35/8.38 2015-11-23,Lua 5.1,2.9.2,<removed_for_SO>"
[Mon Aug 27 23:05:58.060493 2018] [:notice] [pid 32730] ModSecurity: StatusEngine call successfully sent. For more information visit: http://status.modsecurity.org/
[Mon Aug 27 23:05:58.105989 2018] [:notice] [pid 32734] FastCGI: process manager initialized (pid 32734)
[Mon Aug 27 23:05:59.016019 2018] [mpm_prefork:notice] [pid 32731] AH00163: Apache/2.4.18 (Ubuntu) mod_fastcgi/mod_fastcgi-SNAP-0910052141 OpenSSL/1.0.2g configured -- resuming normal operations
[Mon Aug 27 23:05:59.017563 2018] [core:notice] [pid 32731] AH00094: Command line: '/usr/sbin/apache2'
[Mon Aug 27 23:06:59.489457 2018] [mpm_prefork:notice] [pid 32731] AH00169: caught SIGTERM, shutting down

I see the issues with APR and PCRE not having the same version, but I had read in a different thread that this should not be causing the issue I am seeing.

If there is anything else I can setup to help figure this out - that would be appreciated, or if someone else has run across something similar that would be helpful too.

I've already tried looking at HTOP to see what processes are running - nothing out of the ordinary there, I do see a CPU spike AFTER I see the restart command (Which makes sense given apache is restarting)

We do have logrotate installed (another common thing I have seen) however logrotate is set to run weekly, so I don't think that its causing this either.

We're hosting wordpress on the site as well.

Let me know if there is anything else I can add to this that might help.

Checked on cronjobs as well - no cronjobs

BMoe872
  • 1
  • 3
  • Is it happening when someone is accessing particular URL? Is your wordpress fully updated? If you are out of date, perhaps someone is exploiting you somehow? Have you allocated enough memory for Apache/php? Are you running out of memory perhaps? – Zoredache Aug 28 '18 at 00:37
  • It happens exactly ever 1min and 3sec - regardless of traffic to the site. Wordpress is fully updated. Enough memory has been allocated, and I would expect to see a memory error in the logs before the restart if that was the case. Thank you for your comment though. – BMoe872 Aug 28 '18 at 00:45
  • 1
    Well, *something* is sending a SIGTERM, which is fairly straightforward to pin down. Turn on syscall auditing and go hunting. – womble Aug 28 '18 at 02:34
  • So I've enabled syscall auditing (to the best of my knowledge) but that has not given any immediate results. I'm seeing the below in the audit, but looking through ALL the cron jobs on the system, there is nothing calling apache through systemd, so now I'm stuck again. I've looked at each users crontab, and I've looked through the cron.d folder on the system, nothing. type=USER_END msg=audit(1535464081.370:23): pid=24257 uid=0 auid=0 ses=32481 msg='op=PAM:session_close acct="root" exe="/usr/sbin/cron" hostname=? addr=? terminal=cron res=success' – BMoe872 Aug 28 '18 at 14:54

0 Answers0