0

I've been attempting to install the PHP APM plugin for my Web servers, however I've hit a wall and require some assistance.

We are able to install the plugin within issue, update the config without issue, and start the service without issue. However, shortly afterwards the php_agent.log starts showing that it cannot connect to the daemon and continues to fail.

I've checked the daemon and it shows that it is running, however I discovered that the process has actually zombie'd out and is dead. Restarting PHP-FPM removes the zombie and the service works again for a few minutes, but goes back into a zombie state soon after.

I'm able to replicate this problem across all of my web servers. I even spun up a brand new box and deployed it, adding the same configurations as the others, and it too started to zombie shortly after starting.

My configuration is as follows:

  • CentOS 7 (kernel 3.10.0-229.11.1.el7.x86_64)
  • PHP-FPM (5.5.30-1.el7.remi)
  • Nginx (1:1.6.3-6.el7)
  • Newrelic Daemon (4.23.4.113-1)
  • Newrelic PHP5 (4.23.4.113-1)
  • Newrelic PHP5 Common (4.23.4.113-1)

To add insult to injury, it appears that if we leave the zombie for too long, it eventually crashes the Web site across all the servers. Truely, a pain in the rear.

I would appreciate any help or thoughts anyone might have, as this is driving me insane.

Thanks!

eengelking
  • 3
  • 2

3 Answers3

0

I have the same issue before. The only thing I have done is to reinstall it to a new application created on new relic. Good luck. rpm.newrelic.com/accounts/{yourid}/applications

G.T.Shen
  • 1
  • 3
  • Unfortunately, re-installing didn't resolve the issue. @REngland nailed it on the nose, coinciding with NR response. – eengelking Oct 29 '15 at 21:58
0

Do you have a process that is clearing out files residing in /tmp for more than some set time? The agent and daemon communicate via a socket file called /tmp/.newrelic.sock. If it goes away you should see "ENOENT" errors in the logs. You might also have a permission issue for some locations/files.

If the socket file is the problem, consider switching to a TCP port instead of the socket file by setting newrelic.daemon.port in your configuration file (newrelic.ini)

REngland
  • 619
  • 4
  • 5
0

Per NewRelic:

[For CentOS], the default systemd unit file for httpd has the PrivateTmp directive set to true, which means that httpd expects a private temporary directory for use by the process(es). As a result, our PHP agent and daemon can't communicate on a fresh install, as our RPM package installs a socket file when installing the package via yum. This default socket file is outside any private temp directory, which means the agent and daemon can't use to communicate (as a result of the agent being activated via the httpd process), and the correct socket file won't get created during restarts, as the agent and daemon read the location as already existing.

So, to summarize, the problem is two-fold:

  • Private temp directories for the default httpd install prevent the default install of our PHP agent from communicating with the daemon.
  • The default socket file installed by our RPM package prevents a new one from being created in the correct location

The current work-around we have implemented is to delete the default socket file at /tmp/.newrelic.sock, and then to issue a service newrelic-daemon stop, then service httpd stop, and finally a service httpd start. (I've seen a plain restart of httpd not work at times) This problem will hinder all fresh installations of the PHP agent on CentOS 7. Another thing to note is the default unit files for nginx and php-fpm also use private temp directories and are therefore subject to the same potential issues.

eengelking
  • 3
  • 2