Closed tpaz closed 7 years ago
Hi @tpaz,
correct, sup
runs another shell process as a wrapper to set up the correct environment.
You'd need to detach your background process from the parent. Try nohup
or disown
Unix commands.
I might look into removing the wrapper shell, since I was able to resolve the ENV VARs locally via #94. Not sure if I end up with a working solution tho. Let me try..
any updates for this?
I got over it only via running an external bash script. within that script I ran the desired processes in the background but in the end of the script added a wait_pid instruction so that Sup will still consider it foreground.
On Mon, Nov 14, 2016 at 10:59 AM, iven1990 notifications@github.com wrote:
any updates for this?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/pressly/sup/issues/95#issuecomment-260281543, or mute the thread https://github.com/notifications/unsubscribe-auth/ABCBux6AYq-ba_1GsM9sPA_zS5h2RZ0vks5q-CMEgaJpZM4J0PlY .
Rgrds Tomer
Yes, you can run
script: ./your-script.sh
with background processes. I recommend using nohup
and disown
to make sure they still run after you exit from the script.
I did find a way to start background processes without shells scripts, it's a little gross, but it works.
Try this run: line: run: "nohup sleep 63 & sleep 2"
You can then do a PS on a target, and see sleep 63 running.
Try this run: line: run: "nohup sleep 66"
On my system, when I run PS on the target, there is no sleep running.
I believe what this reveals is a race condition where the following is happening:
With the 2nd sleep nohup has time to detach from controlling tty/process, and it will survive after the 2nd sleep finishes.
Without the 2nd sleep nohup is getting crushed before it can detach.
Running a command/process(es) in the background: it seems sup is running bash -c (correct?) to execute remote commands, and I couldn't understand why it was killing commands executed with & (move to bg).
I even used demonize / start-stop-daemon tools to try run my process as daemon to work-around the & issue. it didn't work either. Eventually, I resolved it by wrapping the process in a script that runs whatever I wanted in the bg (running some benchmark tool in parallel to some tuning tool...) while adding "wait" in the end of the script so that sup will not fail on it. that worked nice so far.