Can a custom search determine its search job id?

[Lowell]

Is there anyway to determine the sid or (search job id) from within an executing custom search command?

Is this info available in an environmental variable or in a argument somehwere? Or some kind of API call?

[Lowell]

Here's the best approach I've come up with so far. I would still like a better way to do this, so I'll leave this question open for a while.

Basically setup the search command to run the addinfo command first. I have supports_getinfo = True, so I used the following command in my script:

# streaming, generating, retevs, reqsop, preop
splunk.Intersplunk.outputInfo(False, False, False, True, "addinfo")

Then it's simply a matter of grabbing the info_sid field from the first record, like this:

 (results, dummyresults, settings) = splunk.Intersplunk.getOrganizedResults()
 if len(results) > 0:
     search_id = results[0]["info_sid"]
 else:
     search_id = None

Of course if there are no events/results found, then there is no first record. In my case I don't care because there's no work to do anyways. But I don't want an exception thrown just because there where no matching events in the base search.

---

Update: It appears that in order for the preop command to be executed, you have to set retevs=False (that is "retainsevents"=0). I'm not sure why this is, and if this is an intentional behavior or a bug. Either way it's annoying since I want the event view, and not the results view.

[southeringtonp]

It's not passed in the command line, nor as an environment argument, at least when run directly from the search bar. InterSplunk won't get it either.

You might be able to figure it out by having the script call back into the REST API but it would be messy at best.

The sendemail script has it though, since it uses it in the embedded links. That may be something special about email alerting, or maybe it has to do with being called from a scheduled search.

What are you trying to accomplish? Is the job ID strictly necessary?

[Lowell]

If you look in alert_actions.conf, you'll see the argument searchid=$search_id$ passed to the sendemail search command. So this looks like $search_id$ seems to be inherently known within the alert actions environment. So that explains that example. But doesn't really help in my use case.