We're getting this error when clicking on one of the jobs in "job management":
500 Internal Server Error KeyError: 'vsid'
This page was linked to from http://splunkserver:8000/en-US/app/launcher/job_management.
Here's the detail of the error in web_service.log:
2010-03-15 09:53:26,508 WARNING util:48 - Exception in resurrectSearch when trying to parse the following search - search 0xC0000072 AND shost!=FSCAN AND shost != someipaddress AN D shost !=somehostname duser!=*$ hoursago=62 | stats count(duser) by duser, shost, suser 2010-03-15 09:53:26,543 ERROR
customlogmanager:22 - [15/Mar/2010:09:53:26] HTTP Request Headers: REFERER: http://mparcprd201.uboc.com:8000/en-US/app/search/job_management HOST: mparcprd201.uboc.com:8000
ACCEPT: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,/;q=0.5 ACCEPT-CHARSET: ISO-8859-1,utf-8;q=0.7,*;q=0.3
USER-AGENT: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/532.5 (KHTML, like Gecko) Chrome/4.0.249.89 Safari/532.5
CONNECTION: keep-alive COOKIE: session_id_8000=b279d0119ee1bd6c60066a6701908238db897e12 Remote-Addr: 10.150.28.71
ACCEPT-LANGUAGE: en-US,en;q=0.8
ACCEPT-ENCODING: gzip,deflate,sdch 2010-03-15 09:53:26,544 ERROR
customlogmanager:22 - [15/Mar/2010:09:53:26] HTTP Traceback (most recent call last): File "/opt/splunk/lib/python2.6/site-packages/cherrypy/_cprequest.py", line 606, in respond cherrypy.response.body = self.handler() File "/opt/splunk/lib/python2.6/site-packages/cherrypy/_cpdispatch.py", line 25, in call return self.callable(*self.args, **self.kwargs) File "/opt/splunk/lib/python2.6/site-packages/splunk/appserver/mrsparkle/lib/routes.py", line 307, in default return route.target(self, **kw) File "", line 1, in
File "/opt/splunk/lib/python2.6/site-packages/splunk/appserver/mrsparkle/lib/decorators.py", line 28, in rundecs return fn(*a, **kw) File "", line 1, in File "/opt/splunk/lib/python2.6/site-packages/splunk/appserver/mrsparkle/lib/decorators.py", line 76, in check return fn(self, *a, **kw) File "", line 1, in File "/opt/splunk/lib/python2.6/site-packages/splunk/appserver/mrsparkle/lib/decorators.py", line 116, in check_login return fn(self, *a, **kw) File "", line 1, in File "/opt/splunk/lib/python2.6/site-packages/splunk/appserver/mrsparkle/lib/decorators.py", line 137, in handle_exceptions return fn(self, *a, **kw) File "/opt/splunk/lib/python2.6/site-packages/splunk/appserver/mrsparkle/controllers/view.py", line 1099, in render templateArgs = self.buildViewTemplate(app, view_id, action, q, sid, s, earliest, latest, remote_server_list) File "/opt/splunk/lib/python2.6/site-packages/splunk/appserver/mrsparkle/controllers/view.py", line 1016, in buildViewTemplate if len(savedSearchObject['vsid']) > 0: File "/opt/splunk/lib/python2.6/site-packages/splunk/entity.py", line 449, in getitem return self.properties[key] KeyError: 'vsid'
This happens when an alert is created in manager, instead of in the search app. We neglect to create the viewstate ID (vsid) that the UI wants to figure out how to show the search. As a result, the UI fails saying "hey, I don't know how to show you this search" in its own inscrutible way.
Workaround, create a vsid for the search (someone will have to provide some more detail here.. I don't know the steps).
Solution, use Splunk 4.0.10 or later which doesn't muck this up.
This happens when an alert is created in manager, instead of in the search app. We neglect to create the viewstate ID (vsid) that the UI wants to figure out how to show the search. As a result, the UI fails saying "hey, I don't know how to show you this search" in its own inscrutible way.
Workaround, create a vsid for the search (someone will have to provide some more detail here.. I don't know the steps).
Solution, use Splunk 4.0.10 or later which doesn't muck this up.
I was positing that the search was created in manager. IF that is not the case, it is not the cause of the problem.
@kode - If I'm reading @k8to's post correctly, even though this happened in search, the job-management URL it came from is part of Manager, hence you ran into this problem in Manager. Regardless, sounds like this is fixed in 4.0.10, so an upgrade should solve the issue.
In our case, it was done in search, not manager.