I am attempting to run a scheduled BASH scripted input on UF 7.2.x on Ubuntu 16 or later.
The script does some preparatory work and then STOPS the UF.
It then needs to change some things in the UF environment, and then restart the UF.
Testing it from the CLI shows that the script works according to plan, HOWEVER,
when running it as a scripted input, the last line that gets executed is the SPLUNK STOP command.
I know the reason is that when the UF stops, it destroys the process tree that is running the script.
From reading older threads on similar issues, I find that this behavior used to not be the default. People were complaining that things were continuing to run, and chewing up resources even though the UF had been stopped. I understand that concern, however in this case, I really need it to keep running, even though that no longer appears to be the default behavior.
I have attempted using a wrapper script using the bash and & parameters, as well as NOHUP and SCREEN. All to no avail. They all get killed when the UF stops. I have attempted using a .path file to call the script. Same result.
How can a fork something that is no longer dependent on the UF process for this one script?
Any help is greatly appreciated!
Not really a Splunk issue as you probably know 😉 But here to help anyway 🙂
Since you tried
screen already without success have you considered using
You can find a good example here https://superuser.com/a/172476
Hope that helps ...
Thank for the quick response. Unfortunately
setsid didn't work either.
They all seem to be doing the right thing IF I am trying to detach from the TTY session that I am using. However, I want to detach the bash script from the
splunkd process, and I can't seem to figure out how to do that.
I know this is not directly related to Splunk, but I have searched the Linux forums as well, and cannot find specifics on how to do it. I may just not know how to ask the question properly there. I had hoped that since I was trying to do it under Splunk scripted inputs, someone here may have run into it before.