Having trouble spawning child processes using exec-script
37 views
Skip to first unread message
Jon Woods
May 27, 2014, 9:18:57 AM5/27/14
to palle...@googlegroups.com
Hi there.
My team's got a Jenkins build pipeline (automated using JobDSL, but soon hopefully Pallet too) which we want to point at our new and nearly shiny Pallet/VMFest infrastructure. A barrier we're currently facing is that we can't use Pallet to spawn processes on the VM guest using exec-script*. We were hoping to use Pallet/VMFest to fling our existing Jenkins scripts (eg for firing up new persistent instances of a web app) onto our VMs.
The simplest test case which demonstrates this:
(pallet.api/lift my-group :compute compute-service-provider :phase (pallet.api/plan-fn (pallet.actions/exec-script* "touch /home/jon/the-script-ran")))
produces a file on the VM guest called the-script-ran, showing that it ran. But if we background the touch invocation using & or screen, then the same file isn't created, so it seems as though the process is never spawned.
We've tried lots of things, including not backgrounding the invoked script but doing the backgrounding inside it, using bash -c, etc etc, but are currently stumped.
Anyone have any ideas as to why this might be the case? I realise this is dangerously close to a core *nix question.
Jon
My team's got a Jenkins build pipeline (automated using JobDSL, but soon hopefully Pallet too) which we want to point at our new and nearly shiny Pallet/VMFest infrastructure. A barrier we're currently facing is that we can't use Pallet to spawn processes on the VM guest using exec-script*. We were hoping to use Pallet/VMFest to fling our existing Jenkins scripts (eg for firing up new persistent instances of a web app) onto our VMs.
The simplest test case which demonstrates this:
(pallet.api/lift my-group :compute compute-service-provider :phase (pallet.api/plan-fn (pallet.actions/exec-script* "touch /home/jon/the-script-ran")))
produces a file on the VM guest called the-script-ran, showing that it ran. But if we background the touch invocation using & or screen, then the same file isn't created, so it seems as though the process is never spawned.
We've tried lots of things, including not backgrounding the invoked script but doing the backgrounding inside it, using bash -c, etc etc, but are currently stumped.
Anyone have any ideas as to why this might be the case? I realise this is dangerously close to a core *nix question.
Jon
G Gordon Worley III
May 27, 2014, 1:23:50 PM5/27/14
to palle...@googlegroups.com
Someone else can probably speak to exactly why this is happening (if I ever figured it out I don't remember now), but I've seen exactly this same behavior. The solution in my case was to just do what I should have done to begin with and run the process using supervision (in my case runit, but init should be sufficient).
--
You received this message because you are subscribed to the Google Groups "pallet" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pallet-clj+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Linus Ericsson
May 27, 2014, 2:08:52 PM5/27/14
to palle...@googlegroups.com
Which user do the script run as when &:ed? Can you try to touch /tmp/thescriptran and see the owner of that file?
/Linus
Jon Woods
May 27, 2014, 2:10:50 PM5/27/14
to palle...@googlegroups.com
Thanks for that - I'll look into it for the future.
I believe I've solved it by other means, thanks to Hugo here: I just needed set -m in the context of scripts which were to be run in persistent child processes. That bash option enables job control, and (I understand this only generally) presumably stops the parent process from exiting before the child has had a chance to detach itself.
I believe I've solved it by other means, thanks to Hugo here: I just needed set -m in the context of scripts which were to be run in persistent child processes. That bash option enables job control, and (I understand this only generally) presumably stops the parent process from exiting before the child has had a chance to detach itself.
Jon Woods
May 27, 2014, 3:14:25 PM5/27/14
to palle...@googlegroups.com
As it happens, the scripts run as root, for reasons I'm not entirely sure of! and so that's something we'll need to fix. However, the original problem was that the scripts weren't being run at all, not as anyone: the parent process was dying before the child process had time to detach.
On Tuesday, May 27, 2014 7:08:52 PM UTC+1, Kowal wrote:
Which user do the script run as when &:ed? Can you try to touch /tmp/thescriptran and see the owner of that file?
Someone else can probably speak to exactly why this is happening (if I ever figured it out I don't remember now), but I've seen exactly this same behavior. The solution in my case was to just do what I should have done to begin with and run the process using supervision (in my case runit, but init should be sufficient).
On Tue, May 27, 2014 at 6:18 AM, Jon Woods wrote:
Hi there.
My team's got a Jenkins build pipeline (automated using JobDSL, but soon hopefully Pallet too) which we want to point at our new and nearly shiny Pallet/VMFest infrastructure. A barrier we're currently facing is that we can't use Pallet to spawn processes on the VM guest using exec-script*. We were hoping to use Pallet/VMFest to fling our existing Jenkins scripts (eg for firing up new persistent instances of a web app) onto our VMs.
The simplest test case which demonstrates this:
(pallet.api/lift my-group :compute compute-service-provider :phase (pallet.api/plan-fn (pallet.actions/exec-script* "touch /home/jon/the-script-ran")))
produces a file on the VM guest called the-script-ran, showing that it ran. But if we background the touch invocation using & or screen, then the same file isn't created, so it seems as though the process is never spawned.
We've tried lots of things, including not backgrounding the invoked script but doing the backgrounding inside it, using bash -c, etc etc, but are currently stumped.
Anyone have any ideas as to why this might be the case? I realise this is dangerously close to a core *nix question.
Jon
--
You received this message because you are subscribed to the Google Groups "pallet" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pallet-clj+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "pallet" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pallet-clj+unsubscribe@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages