Deployment Architecture

Failed to install app

joonradley
Path Finder

Hi,

After redeploying an app today I received the following errors and just cannot find the reason fro this:

11-21-2011 15:57:06.718 +0200 ERROR DeployedApplication - Failed to install app : C:\Program Files\Splunk\etc\apps\collectors_db2. Cannot update application info: /nobody/collectors_db2/app/install/state = enabled: Metadata could not be written: /nobody/collectors_db2/app/install/state: {  }, removable: yes

11-21-2011 15:57:07.405 +0200 ERROR ConfObjectManagerDB - Cannot initialize: C:\Program Files\Splunk\etc\apps\collectors_db2\metadata\local.meta

Using Splunk 4.2.4 on Windows 2008 R2 running as LocalSystem service account.

I have changed the permission on the folders, but the issue persist.

Can anyone point me in the right direction?

Thx

Tags (1)
1 Solution

sdwilkerson
Contributor

joonradley,

I have started seeing this error at several customer sites after upgrading them to Splunk-4.2.4. I never saw it prior to 4.2.4.
I believe this is a logic bug of some kind (it looks like a change which is inappropriately measuring for local.meta's existence).
The fix is going to be when Splunk puts out a patch.
In the meantime, you can create an empty local.meta file in your apps and the error goes away (in the cases where I have seen this).

I use a little for loop to implement this solution:

  1. cd $SPLUNK_HOME/etc/apps (or $SPLUNK_HOME/etc/deployment-apps)
  2. for i in ls -d; do [ ! -f $i/metadata/local.meta ] && touch $i/metadata/local.meta; done;

Reload and all is well.

I would love to hear someone from Splunk provide more details on this.

Best,
Sean

View solution in original post

virtualpony
Path Finder

I'm using 4.3 deploy server and 4.3 universal forwarders when deploying an app, but the metadata directory and local.meta file does not get created. If I try to create the directory and file, it gets deleted.

I tried removing the entire app from the forwarding system and reloading the deploy server, but the same issue happens.

0 Karma

virtualpony
Path Finder

None of the other apps I deployed have the metadata dir on the deployment server and they work. In any case, I added the metadir/local.meta to the problematic app. It is still throwing issues:

2/24/12 9:16:43.122 AM

Cannot load to modify: C:\Program Files\SplunkUniversalForwarder\etc\apps\admon\metadata\local.meta

02-24-2012 09:16:43.122 -0800 ERROR ConfObjectManagerDB - Cannot load to modify: C:\Program Files\SplunkUniversalForwarder\etc\apps\admon\metadata\local.meta

4

2/24/12 9:16:43.122 AM

Cannot open ini file for parsing: The system cannot find the path specified.

0 Karma

sdwilkerson
Contributor

virtualpony,
The metadata direcotry and the underlying local.meta must exists in a deployment-server environment in order for the app to be installed on the deployment client.

tpaulsen
Contributor

Strange...we deploy from a 4.1.7 Deployment Server to a Splunk 4.3 Universal Forwarder and get the same error (under Linux SLES11).

The workaround described above did work here also.

0 Karma

tpaulsen
Contributor

thank you. The strange part is, that it does not happen with every deployment. I am currently upgrading our Forwarder from 4.1 to 4.3. We´ll see if this happens more often.

0 Karma

sdwilkerson
Contributor

tpaulsen,
My answer above still applies in 4.3. Splunk requires local.meta to exist in the app on the deployed system so it can write information locally; unfortunatley they didn't build in a routine to create the file if it didn't exist.
The work-around is still to create these files on the deployment server prior to deployment.

0 Karma

jbsplunk
Splunk Employee
Splunk Employee

This is documented in the 4.2.4 known issues with a workaround:

http://docs.splunk.com/Documentation/Splunk/latest/releasenotes/KnownIssues

Under certain circumstances when deploying apps in 4.2.4, you'll get an error on the deployment client that says: 'cannot update application info: /nobody/appname/app/install/state = enabled: Metadata could not be written: /nobody/appname/app/install/state: { }, removable: yes.' The workaround is to create a file and folder /metadata/local.meta in the app in the deployment-server.(SPL-45019) 

jbsplunk
Splunk Employee
Splunk Employee

It was fixed in 4.3.1

0 Karma

halr9000
Motivator

The issue is no longer on the known issues list. I just emailed support to make sure that they are still tracking it in case this is a regression.

0 Karma

sdwilkerson
Contributor

Good catch on the KnownIssues.

0 Karma

wrangler2x
Motivator

That link takes you to the latest known issues. Here is one that goes to the 4.2.4 known issues:

http://docs.splunk.com/Documentation/Splunk/4.2.4/ReleaseNotes/KnownIssues

I've found that if you delete the deployment app directory on the forwarder out of $SPLUNK_HOME/etc/apps and restart splunkd the app will be re-installed and the problem goes away. This happened on one of my forwarders and that is what I did there. But when it happened on two other forwarders this week I went looking to see if it was a known issue and found this. I've placed the metadata/local.meta in all my apps on the deployment server because the folks that own these three systems don't want to do an upgrade to 6.1.4, which is what I'm installing on all new forwarders and when I do upgrades. The thing is, these forwarders have run a long time without this issue happening, and I wonder what triggered it on these three in a two week period. Odd.

0 Karma

sdwilkerson
Contributor

joonradley,

I have started seeing this error at several customer sites after upgrading them to Splunk-4.2.4. I never saw it prior to 4.2.4.
I believe this is a logic bug of some kind (it looks like a change which is inappropriately measuring for local.meta's existence).
The fix is going to be when Splunk puts out a patch.
In the meantime, you can create an empty local.meta file in your apps and the error goes away (in the cases where I have seen this).

I use a little for loop to implement this solution:

  1. cd $SPLUNK_HOME/etc/apps (or $SPLUNK_HOME/etc/deployment-apps)
  2. for i in ls -d; do [ ! -f $i/metadata/local.meta ] && touch $i/metadata/local.meta; done;

Reload and all is well.

I would love to hear someone from Splunk provide more details on this.

Best,
Sean

joonradley
Path Finder

thank you. worked perfectly

0 Karma
Get Updates on the Splunk Community!

Enterprise Security Content Update (ESCU) | New Releases

In December, the Splunk Threat Research Team had 1 release of new security content via the Enterprise Security ...

Why am I not seeing the finding in Splunk Enterprise Security Analyst Queue?

(This is the first of a series of 2 blogs). Splunk Enterprise Security is a fantastic tool that offers robust ...

Index This | What are the 12 Days of Splunk-mas?

December 2024 Edition Hayyy Splunk Education Enthusiasts and the Eternally Curious!  We’re back with another ...