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

Ghost 'newrelic.ini' APM reporting


I’m trying to trace down ‘ghost’ entries in my APM application list.

As a test, I created a new AWS EC2 linux server and have two simple PHP applications running under different Apache VirtualHosts, each has their own newrelic.appname (“test2”, “test3”), plus I have the 000-default VirtualHost running under the newrelic.appname “default”. I have configured the /etc/php5/mods-available/newrelic.ini with appname “newrelic.ini”.

I have removed the newrelic PHP CLI module as per Newrelic.appname causing two APM entries, so I should get no APM reporting via the PHP CLI and expect to only get reporting for “test2” and “test3” which are receiving traffic. I understand any web traffic to the server which is caught by 000-default (e.g. http://{ipaddress}) would report as “default”.

However, when I look at my APM applications I see “test2”, “test3” APM reporting as expected, but I also see a ‘newrelic.ini’ entity reporting. Why? Any traffic to the site is recorded against the “test2”, “test3” or the “default” VirtualHosts correct? And PHP CLI traffic is disabled from newrelic reporting - so where does the reporting for “newrelic.ini” come from? What New Relic events will cause an APM entity to be created?


One option for cases like this is to set your daemon loglevel to “debug” and look for the Connect request. It will include a bit like this in the json payload it sends to New Relic when the app connects. The connect request will look like this:

2018/10/22 11:26:12.300459 (62525) Debug: command='connect'

And near the end of that logentry will be something like this:


The dispatcher will include the version of PHP and the handler (FPM, Apache, CLI, etc)

To change the daemon’s log level, if you have the default Agent startup method you’ll need to edit your newerelic.ini with this line:

newrelic.daemon.loglevel = "debug"

And then kill all newrelic-daemon processes and restart Apache (or FPM, etc) to pick up the change and automatically start the newrelic-daemon with the debug logs.

The logs themselves are in /var/log/newrelic/newrelic-daemon.log

Hope that helps narrow it down! There must be some PHP configuration somewhere with a PHP value for “newrelic.appname” set to “newrelic.ini” or our API is being called to set the appname within a PHP script.


There must be some PHP configuration somewhere with a PHP value for “newrelic.appname” set to “newrelic.ini”

Yes there is. I set this specifically. What I can’t understand is what events/actions are causing it to report under this appname, since all traffic is through VirtualHosts with different appnames and the PHP CLI is disabled from newrelic reporting.

I will debug as suggested to find out more.


The entries I’m getting have [“Dispatcher”,“7.0.32+cli”], what I can’t understand is how this reporting is triggered since I have removed newrelic from /etc/php/7.0/cli/conf.d/, which should mean PHP CLI is no longer triggering New Relic reporting (as per Newrelic.appname causing two APM entries)?


Are you seeing New Relic extension loaded from php -i? The newrelic.ini contains so removing it will normally cause the extension to not load.


Hi, no it doesn’t show from php -i, so I’m not sure what is triggering the reporting to the appname under newrelic.ini, since the only traffic should be under other appnames and PHP CLI is disabled from New Relic reporting?


Hi @room9

It looks like we currently working on this with you in an open ticket open. Once we figure out what’s occurring here, we will certainly update this post to ensure anyone else who might be experiencing this or something similar might find the solution helpful. Thanks!


So we traced the issue and the problem is:

  • cron runs /usr/lib/php/sessionclean every 30mins on this Ubuntu system
    • CRON[1752]: (root) CMD ( [ -x /usr/lib/php/sessionclean ] && /usr/lib/php/sessionclean)
  • the sessionclean script passes the Apache *.ini file as a configuration option - so the PHP CLI is run, which by default would have the new relic extension disabled, but in this case will load the new relic extensions as it is enabled under the Apache PHP config
  • Because the PHP command is run as CLI, it uses the default appname, creating a new Application entity in New Relic since there is no VirtualHost in this scenario

Therefore with default PHP installs on Ubuntu it’s not possible to have New Relic APM reporting only using VirtualHost appnames, it will always create a default APM entry, which makes it difficult to trace since multiple servers will send “PHP Application” by default, as will any VirtualHost not correctly configured to report it’s own appname.

To prevent this issue you must edit /usr/lib/php/sessionclean to set newrelic.enabled = 'false':

session_config=$(PHP_INI_SCAN_DIR=/etc/php/${version}/${conf_dir}/conf.d/ php${version} -c /etc/php/${version}/${conf_dir}/php.ini -d "newrelic.enabled = 'false'" -r 'foreach(ini_get_all("session") as $k => $v) echo "$k=".$v["local_value"]."\n";')


@room9 Thanks for confirming you got this resolved. And thanks so much for sharing the detailed solution.