I'm working with a search that starts by filtering for all process events in Windows and then sending them to a lookup file using outputlookup with the 'append' flag set to false so it resets each run. For example, process_events.csv
The following lines then applies various filters to the search, brining it down to only a small handful of events.
The next lines then use the lookup command to pull from the new lookup file created at the start with all the process events prior to filtering. Using it, I create fields showing the grandparent process for the remaining process events.
With the grandparent process added, I use a subsearch in the below manner to filter out events which match a separate lookup table I use as a whitelist.
| search NOT
[ inputlookup whitelist
| fields + src_hostname user grandparent_process_path parent_process_path process_path]
The issue, I'm afraid, is how Splunk's order of operations works. When the search runs on its schedule, it's like the lookup commands are parsed before the outputlookup command despite that not being how the search is written. Because of this, I feel like it checks the prior instance of process_events.csv before it's been regenerated by outputlookup with fresh data. As such, the grandparent_process_path field comes back as "n/a" rather than being filled properly so that it can be checked against the whitelist properly.
Am I thinking along the right lines here? Is there some nuance of outputlookup I'm missing? If so, any ideas on fixing it, or am I gonna need to scrap this whole idea to add in grandparent processes to process event logs?
This is basically the same problem you asked about last month (which you said you had solved), however, pursuing the other solutions offered at the time might prove more helpful in this instance?
Subsearches are performed first, before the main search executes. That's why there's nothing for the lookup command to find.