I just installed 4.1.1 in the probably vain hope that some of the strange errors since 4.1 install would disappear. This has broken the splunk installation and resulted in a P1 case.
My question is if anybody has ever tried to look into the steps involved in a splunk installation, and what would be involved in that if so? There seems to be an issue with an unbound local variable, which I would assume has something to do with my own personal installation:
An unforeseen error occurred:
Exception: <type 'exceptions.UnboundLocalError'>, Value: local variable 'files_to_export' referenced before assignment
Traceback (most recent call last):
File "D:\Program Files\Splunk\Python-2.6\Lib\site-packages\splunk\clilib\cli.py", line 1076, in main
parseAndRun(argsList)
File "D:\Program Files\Splunk\Python-2.6\Lib\site-packages\splunk\clilib\cli.py", line 934, in parseAndRun
retVal = cList.getCmd(command, subCmd).call(argList, fromCLI = True)
File "D:\Program Files\Splunk\Python-2.6\Lib\site-packages\splunk\clilib\cli.py", line 264, in call
return self.func(args, fromCLI)
File "D:\Program Files\Splunk\Python-2.6\Lib\site-packages\splunk\clilib\control_api.py", line 33, in wrapperFunc
return func(dictCopy, fromCLI)
File "D:\Program Files\Splunk\Python-2.6\Lib\site-packages\splunk\clilib\_internal.py", line 208, in firstTimeRun
migration.autoMigrate(isDryRun)
File "D:\Program Files\Splunk\Python-2.6\Lib\site-packages\splunk\clilib\migration.py", line 1885, in autoMigrate
suggestGlobalExports_4_1()
File "D:\Program Files\Splunk\Python-2.6\Lib\site-packages\splunk\clilib\migration.py", line 1278, in suggestGlobalExports_4_1
isSearchScript))
File "D:\Program Files\Splunk\Python-2.6\Lib\site-packages\splunk\clilib\migration.py", line 1249, in suggestExport
if files_to_export and not files_already_exported:
UnboundLocalError: local variable 'files_to_export' referenced before assignment
Feel free to brave, if you want. Armed with the idea that cli.py->main() is the entry point from the splunk executable into the python code, most of the rest of it is fairly straightforward python, but a lot of what it's trying to do is quite specific to splunk.
If you've got time to kill and want to debug a bug you're seeing, you can grab the logger we use and coerce it into printf style debugging. Sounds like a waste of time to me, though. In this case I presume that files_to_export is set in a conditional path that was traversed in our testing, but not for you.
Okay, actual fail here is an incorrect exception catch combined with an incorrect exception handling.
Either the glob or the filter tossed an exception (that the migration code hid), and then it didn't handle the lack of a variable correctly. You could edit migration.py:
def suggestExport(bundle, metadata, subdir, type, is_correct_file_type):
base = bundle.location()
try:
candidate_files = glob.glob(os.path.join(base, subdir, '*'))
should be hacked to
def suggestExport(bundle, metadata, subdir, type, is_correct_file_type):
base = bundle.location()
search_dir = os.path.join(base,subdir)
if not os.path.isdir(search_dir):
return False # no objects -> no export needed
try:
candidate_files = glob.glob(os.path.join(search_dir, '*'))
I'm filing the bug.
Feel free to brave, if you want. Armed with the idea that cli.py->main() is the entry point from the splunk executable into the python code, most of the rest of it is fairly straightforward python, but a lot of what it's trying to do is quite specific to splunk.
If you've got time to kill and want to debug a bug you're seeing, you can grab the logger we use and coerce it into printf style debugging. Sounds like a waste of time to me, though. In this case I presume that files_to_export is set in a conditional path that was traversed in our testing, but not for you.
Okay, actual fail here is an incorrect exception catch combined with an incorrect exception handling.
Either the glob or the filter tossed an exception (that the migration code hid), and then it didn't handle the lack of a variable correctly. You could edit migration.py:
def suggestExport(bundle, metadata, subdir, type, is_correct_file_type):
base = bundle.location()
try:
candidate_files = glob.glob(os.path.join(base, subdir, '*'))
should be hacked to
def suggestExport(bundle, metadata, subdir, type, is_correct_file_type):
base = bundle.location()
search_dir = os.path.join(base,subdir)
if not os.path.isdir(search_dir):
return False # no objects -> no export needed
try:
candidate_files = glob.glob(os.path.join(search_dir, '*'))
I'm filing the bug.
Seems to me like it's pretty much a bug that you should open a case on with Splunk Support/Engineering to get fixed.
Feel free to look I guess, but if you're going from 4.0, there's very little config that needs changing, and you could fix it all yourself as it comes up. Probably easier than trying to debug the migration script (if you can get past the migration script).
yeah... the trace back goes to _intern.py, control_api.py cli.py... all sorts of fun. I do have a case in atm.
Maybe the title should have said something like, how brave should we be when digging into all the python scripts?
I can see that it is the migration.py script having the issue, which I suppose should be obvious since I was trying to do a migration.