HI Timothy Sorry if it was not made clear, I thought I had stated that the process attaches to the Process ID 1 when running from the command line. I was trying to talk in general terms and not about a specific instance, as once this is solved it is a patten that can be applied to other similar processes.
The thing is that the process is not long running, it initially creates a process then attaches it to Process ID 1 and then exits. So if you ran it from the command line it would initialise the process and then make it run in the background so that it is not killed when the shell is exited. What I have found is a script that starts the process using nohup and & to spawn the process in the background and survives shell exit etc, and then waits for the port to be active. In this way ansible can run the shell / command and pseudo wait for the process to complete. Just because the port is active may not mean the process has been successful, that is hidden in the messages being generated to a file. I can then replay the file back to STDOUT and get ansible to check it was okay. In effect i have a wrapper that is ansible friendly, just now I have to sell this to the rest of my team that this pattern is the way we need to move forward, as this helps bootstrap the application being deployed. I have an actual service that I manage through init.d, but it does a lot more than just start the process, in fact it performs 2 other tasks, but this is not something that I can change, not without major testing. I apologise to people if anybody took offence to what I have said. Regards Nicholas Irving On 28 April 2015 at 08:55, Timothy Appnel <[email protected]> wrote: > So a few things here. > > Having just breezed over what WebLogic Node Runner does, I see where > something like service or supervisor is somewhat redundent for you. That > wasn't clear to me from from this thread until I did that though. That's > not the norm for most though and you weren't clear on that so I don't think > its fair to say Brian is missing the point. > > So I think I get what you are trying to do. > > We've been in a similar spot here with long running processes rather than > daemons, but I think what we did applies here. Use the the wait_for > directive right after your shell nohup async task and look for a sign that > the initialization of the previous task has reached a ready state. What is > "ready" will depend on you. In our case it's a specific line in a log file. > > Not ideal or elegant, but it should work. > > Now, based on what I read, it sounds like the elegant solution would be to > create a noderunner module where you can better manage and control the jobs > abstracted from your playbook or role. > > Hope that helps. > > -- > You received this message because you are subscribed to the Google Groups > "Ansible Project" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ansible-project/9e182cb7-e345-470e-9e93-6b12967b85b7%40googlegroups.com > . > For more options, visit https://groups.google.com/d/optout. > -- Nicholas Irving Simple, Accurate, Secure. 04 0007 0562 http://www.darkedges.com/ <http://www.darkedges.com/?gmail> -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAMqs2CZc9tU-Hgbq7xc6o8Nwg6Y6GF%3DXynb8JK7X58mEknFhEw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
