Your data. Anywhere you go.

New Relic for iOS or Android

Download on the App Store    Android App on Google play

New Relic Insights App for iOS

Download on the App Store

Learn more

Close icon

APPINFO reply unknown app


I ran yum update on a CentOs 7 box last night and my PHP Application (a WordPress site) has not been reporting since. The server daemon is running and reporting, the PHP agent is not.

In my php_agent.log, the problem seems to be APPINFO reply unknown app:

2016-10-07 11:43:19.100 -0400 (33832 33832) verbosedebug: daemon connect(fd=4 uds=/tmp/.newrelic.sock) succeeded
2016-10-07 11:43:19.100 -0400 (33832 33832) debug: MINIT processing done
2016-10-07 11:43:19.100 -0400 (33832 33832) debug: late_init called from pid=33832
2016-10-07 11:43:19.101 -0400 (33832 33832) verbosedebug: RINIT processing started
2016-10-07 11:43:19.101 -0400 (33832 33832) debug: added app='Company WordPress' license='4f...f6'
2016-10-07 11:43:19.101 -0400 (33832 33832) verbosedebug: querying app='Company WordPress' from parent=4
2016-10-07 11:43:19.101 -0400 (33832 33832) debug: APPINFO reply unknown app='Company WordPress'
2016-10-07 11:43:19.101 -0400 (33832 33832) debug: unable to begin transaction: app 'Company WordPress' is unknown
2016-10-07 11:43:19.102 -0400 (33832 33832) debug: MSHUTDOWN processing started
2016-10-07 11:43:19.102 -0400 (33832 33832) debug: closed daemon connection fd=4

I’ve tried all of this. The newrelic-daemon does appear to be running when I ps -ef | grep newrelic-daemon.

Any thoughts as to what steps I can take to troubleshoot this issue?



Have you killed all the running daemons after upgrading?
Could you run ps -ef | grep newrelic-daemon, grab all the PIDs (there should be 2 running) and kill them with kill -9 <PID1> <PID2> ...

Run ps again just to double check all daemon processes are gone and then restart your web server.

Let us know how it goes,



I killed the process and restarted the web server. The New Relic agent did not automatically start, so I ran newrelic-install install and then restarted the web server again. I got the same result in the php_agent.log file.


Hi @benharold,

If the agent did not automatically start when the web server was restarted, it is possible you the daemon is set to External (manual) mode, which means the agent is expected to be restarted manually. This can be confirmed if we see a newrelic.cfg file in your /etc/newrelic directory.

More information on External mode and the ways of starting the PHP daemon can be found at the following link:

Can you verify for us whether or not you see this file in your /etc/newrelic directory?


There is no newrelic.cfg file in the /etc/newrelic directory, only a template for that file.


Hi @benharold

So the APPINFO message is basically when the appname set locally can’t be determined as the dashboard exists and is ready to receive metrics from this appname. So it normally means there is a problem of the agent and daemon connection and talking to each other, or the daemon cannot reach New Relic servers.

It sounds like the PHP Agent isn’t connecting to the Daemon because on restart of PHP, should cause the daemon to startup.

Can you try

edit your newrelic.ini (normally found in /etc/php.d/)

Look for the setting

;newrelic.daemon.port = "/tmp/.newrelic.sock"

amend to (note the ; removed to uncomment)

newrelic.daemon.port = "@newrelic-daemon"

Then you need to just double ensure the daemon is dead

killall newrelic-daemon or ps aux | grep newrelic-daemon and kill those PIDs

and restart it by restarting PHP

service httpd restart (if using Apache) or service php-fpm restart if using FPM.

This should cause PHP and the daemon to communicate on an abstract socket, which should be less permissions dependent, I would expect to see the daemon start

service newrelic-daemon status

This should show a running daemon. Hopefully at this point the APPINFO error no longer exists.


The daemon still was not running after all of that, so I set selinux to permissive mode and tried again. Sure enough, it connected and started serving up data.

So I checked the message log with grep setroubleshoot /var/log/messages and found three policy alerts which required the creation of two new semodules in order to get things working under enforcing mode.


@benharold that seems logical. If SELinux is preventing communication then the daemon wouldn’t start and the appname can’t be verified so you can often get that message alongside communication issues.

Definitely if SELinux is enforcing, you may need to configure it to allow the Agent and Daemon the rights to communicate, it sounds like you’ve got things identified and configured now with SELinux is that correct, are you up and running with data?


Yes, it’s working now, thanks. It is possible that setting the daemon port to @newrelic-daemon may have had something to do with it, as I originally had SELinux turned off when attempting to enable APM monitoring.


Switching to @newrelic-daemon wouldn’t have caused SELinux to cause problems, my expectation is that if you enable SELinux even existing connections are impacted by the new rules. So I would have expected connectivity issues from when you enabled SELinux unless you configured SELinux to allow the permissions for Unix Sockets but Abstract sockets requires further config.


Bro, can u look into the loops , for me it is crashing at 456



Seems we got to the bottom of this.
Problem was related to the lack of traffic on this website.

Please note that from our agent version forward, if an application does not receive traffic after 10 minutes it will “grey out” in your dashboard.Showbox App
This does not mean the agent is not running, just that no traffic is being received.
Once traffic is again received the agent will automatically wake up and start reporting again.

Glad to hear it’s all sorted now for you