[TriLUG] init script behaves different when invoked from Ansible playbook??

[Phillip Rhodes via TriLUG]

OK, I think I kinda-sorta have an idea of what is going on now. It is
definitely something to do with the way the script is being invoked
(over ssh using sudo, via ansible, versus locally).  As a test, I
installed the daemonize package, and stuck "daemonize" in front of the
second shell script call in the /etc/init.d/existdb script, and now it
starts and runs OK.

The best thing I can figure at the moment is that somehow the ssh
session being disconnected was killing the script.  I don't know a ton
about how the "service" command works, so I won't swear to it, but it
seems to be something like that.

At any rate, using daemonize works, and as long as I have a usable
approach, I'm happy.


Cheers,


Phil

This message optimized for indexing by NSA PRISM


On Thu, May 11, 2017 at 1:28 PM, Ron Kelley via TriLUG
<trilug at trilug.org> wrote:
> Perhaps the quotes inside the parenthesis was causing an issue (maybe escape them)?  Or, maybe you needed to fully qualify the path of dirname?
>
> Just a thought…
>
>
>
>> On May 11, 2017, at 1:25 PM, Phillip Rhodes (Fogbeam Labs) via TriLUG <trilug at trilug.org> wrote:
>>
>> FWIW, I took the whole dirname business out and temporarily hardcoded the
>> value of the SCRIPTPATH variable and it gets past that point in the script
>> now.  It ultimately fails somewhere else for a different reason, but it
>> looks like the dirname thing was killing the script.
>>
>> I'm not even sure how that's possible though.  First of all, dirname is a
>> pretty innocuous command from what I can tell, and - more to the point - I
>> thought that if something in a subshell returned an error code,it would be
>> return to the parent, which would *not* automatically die.   Hence, you
>> should be able to do something like
>>
>> echo "? = $?" after the subshell and get the exit code.  But I added that
>> and that echo line never executed.  So apparently, somehow, the attempt to
>> invoke dirname in a subshell was causing the parent script to abort.
>>
>> Which is even more confusing given that it works when you run it locally. I
>> even tried plugging in the absolute path to dirname (/bin/dirname) thinking
>> it might be something path related, but still no joy.
>>
>> This whole thing has me befuddled, but then again, I'm not a shell
>> scripting expert to begin with.  :-)
>>
>>
>> Phil
>>
>>
>> On Thu, May 11, 2017 at 1:20 PM, Brian Gerard <bgerard at gmail.com> wrote:
>>
>>> I don't know that it will get you out of your current predicament, but a
>>> safer
>>> way to get the path would be a combination of 'readlink' and 'dirname',
>>> thus:
>>> SCRIPTPATH=$(dirname $(readlink -m $0))
>>>
>>> Brian
>>>
>>> On 05/11/2017 01:06 PM, Phillip Rhodes (Fogbeam Labs) wrote:
>>>>
>>>>
>>>> On Thu, May 11, 2017 at 1:01 PM, Brian Gerard via TriLUG <
>>> trilug at trilug.org
>>>> <mailto:trilug at trilug.org>> wrote:
>>>>
>>>>    When you say it dies in the middle, is there a particular point at
>>> which
>>>>    it dies every time?  Ie - you added a bunch of debugging echoes in
>>> there;
>>>>    can you say what it's trying to do when it dies?  If not, I'd
>>> recommend
>>>>    adding more and appending to a log in /tmp or something to see if
>>> you can
>>>>    pinpoint where it's failing.
>>>>
>>>>
>>>> Yes, it always fails dies (or hangs, I just realized it might still be
>>> running)
>>>> at the same place.  It's trying to do this business:
>>>>
>>>> SCRIPTPATH=$(dirname "$0")
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>    FWIW, the first thing that popped into my brain was the possibility
>>> that
>>>>    Ansible might have mucked about with the shell syntax, if you're
>>> handling
>>>>    that script as a "template" rather than a "file", but since it seems
>>> to
>>>>    work from outside of Ansible, I'm less sure of that.  It might be
>>> worth
>>>>    looking at anyway, just to check.  Diffing the source script and the
>>> installed
>>>>    version, iow.
>>>>
>>>>
>>>> Oh yeah, that's a good thought.  I was thinking in terms of "I'm not
>>> explicitly
>>>> doing any
>>>> substitution stuff in here" and was treating the template as equivalent
>>> to a
>>>> static file.  That
>>>> is probably a bad idea, even if it isn't directly the cause of my
>>> problem here.
>>>>
>>>>
>>>> I'm trying it again now with the script spitting out $BASHPID at the
>>> beginning
>>>> to (hopefully) I can determine if maybe it's hung, as opposed to the
>>> process
>>>> having aborted.
>>>>
>>>>
>>>> Phil
>>>>
>>>
>>>
>> --
>> This message was sent to: Ron Kelley <rkelleyrtp at gmail.com>
>> To unsubscribe, send a blank message to trilug-leave at trilug.org from that address.
>> TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug
>> Unsubscribe or edit options on the web        : http://www.trilug.org/mailman/options/trilug/rkelleyrtp%40gmail.com
>> Welcome to TriLUG: http://trilug.org/welcome
>
> --
> This message was sent to: Phillip Rhodes <motley.crue.fan at gmail.com>
> To unsubscribe, send a blank message to trilug-leave at trilug.org from that address.
> TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug
> Unsubscribe or edit options on the web  : http://www.trilug.org/mailman/options/trilug/motley.crue.fan%40gmail.com
> Welcome to TriLUG: http://trilug.org/welcome