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

[Mun]

Hi Assaf,

Firstly, I've changed the structure of my scripts to avoid this
altogether; but, it would have nice had it worked.
See my comments below.

On Thu, Mar 22, 2018 at 2:42 PM, Assaf Gordon <address@hidden> wrote:
> Hello,
>
> slightly off-topic, but perhaps it'll help:
>
>> 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
>>> ========================================
>
> There seem to be several strange things here:
>
> 1. qsub submits a job to the grid engine (and I assume it is SGE = Sun Grid 
> Engine
> based on the paramaters). The job (your script) will run on a different 
> machine
> (one of the SGE nodes).

Correct: I'm using SGE.


> 2. Using "-b yes" means that you are executing a binary file (e.g. compiled C 
> program)
> as opposed to a shell script. But you *are* queueing a shell script.
> So why use "-b yes" ?

I have found that any executable--even a script--requires use of "-b yes".


> 3. If "gxmessage" is GTK-xmessage [1] then it is a graphical program
> that needs X11 display. But you will certainly not have X11 connection
> on the SGE node that actually runs the job (i.e. the "$DISPLAY" variable
> will be empty, and gxmessage will fail like so:
>
>   $ DISPLAY= gxmessage
>   Unable to init server: Could not connect: Connection refused
>   gxmessage: unable to initialize GTK
>
> So it is not entirely clear what you are aiming to do here.
>
> [1] http://manpages.ubuntu.com/manpages/trusty/man1/gxmessage.1.html

We do have X11 on our qhosts and they are able to push an X11 window
back to the user's display.


> 4. A typical SGE job is scheduled (queued) to be run later (when an SGE
> node is available, which might be immediately). The job will be active
> until the main script is done.
> So why execute a program in the background with nohup?
> Do you want to try and leave a background program running on the SGE node
> and keep consuming resources after the job is officially over?

Pretty much, yes.  It's not really consuming any significant resources
though; it's just the gxmessage window showing the status.  And it
will only be up for as long it takes the user to acknowledge that s/he
has seen it--which I admit may be several hours in some cases.

> 5. It is recommended not to redirect STDOUT and STDERR to /dev/null with SGE.
> Typically, 'qsub' will print a job ID (e.g. "Job 12345 submitted"),
> and once the job is completed (on a different node), STDOUT and STDERR of the 
> job
> will be saved in your $HOME directory as "myScript.o12345" and 
> "myScript.e12345".
> (o=out, e=err). This will quickly show you what errors are encounterd
> (e.g. "gxmessage" will complain about missing $DISPLAY).

I wasn't redirecting the file descriptors for the qsub; only for the gxmessage.

Again, I have a workaround so this thread can be closed.  I would like
to thank everyone for their comments and suggestions!

Best regards,

-- 
Mun

>
>
> HTH,
>  - assaf