help-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-bash] Fwd: Proper use of nohup within here-document?


From: Mun
Subject: Re: [Help-bash] Fwd: Proper use of nohup within here-document?
Date: Thu, 22 Mar 2018 12:32:26 -0700

Hi Greg,


On Thu, Mar 22, 2018 at 12:16 PM, Greg Wooledge <address@hidden> wrote:
> On Thu, Mar 22, 2018 at 12:04:20PM -0700, Mun wrote:
>> My here-document looks something like this:
>>
>> ========================================
>> cat >myScript <<@EOF
>> #! /bin/bash
>>
>> date > showMe.txt
>> nohup gxmessage -timeout 0 -file showMe.txt > /dev/null 2>&1 &
>>
>> @EOF
>>
>> chmod 777 myScript
>> qsub -b yes -sync n ./myScript
>> ========================================
>
> So it's a script that writes a second script, and then executes the
> second script.  There is no execution of background commands during the
> here-document processing at all.  The background process is launched
> by the second script.

Correct.  Sorry for my fuzzy description.

> P.S. 777 permissions are just wrong.  755 would be much more reasonable.

I agree.  In fact, I'm typically a 750 person.  I had used 777 during
alpha testing and will change it before releasing the script.


>> Note the last line with the qsub command.  The whole purpose of the
>> here-document is to package up a set of commands into a script form
>> that will be dispatched to another server for execution using a "grid"
>> tool (aka load sharing facility).
>>
>> The commands run fine except I can't figure out a way for gxmessage to
>> not die when myScript exits.
>
> So the REAL question is how to run a long-running background command on
> a remote system using this "grid" thing, which I'm going to assume is
> something like ssh.
>
> It looks like you've already redirected stdout and stderr, which is
> the normal problem that people encounter when trying to run long-lived
> background processes over ssh.
>
> So, since I don't know anything about "gxmessage" or "grid", I don't know
> that there's anything more I can do for you.  Sorry.  Maybe someone else
> can take a stab at it.
>
> Random guesswork:
>
> (One possibility is that "grid" doesn't simply run a program, but
> instead acts in coordination with some kind of remote overseer/supervisor
> process, and this supervisor kills everything when "grid" disconnects,
> in which case you are actively trying to subvert the design of the
> system you're using.)

Yes, that's possible.  I will look into that.


> (Another is that gxmessage requires a terminal, and dies instantly
> when executed by "grid" which I am assuming does not allocate a
> pseudoterminal by default.)
>
> (I'm sure there are a billion other random things that I just can't
> think of at the moment.)
>
> (Is there a support mailing list for "grid" and/or "gxmessage" that
> might actually know such things?)

Yes, grid has a mailing list as well and I'll make use of it shortly.

Thanks for your ideas and suggestions!

Regards,

-- 
Mun



reply via email to

[Prev in Thread] Current Thread [Next in Thread]