[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 15:08:45 -0700 |
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