[GE users] TMPDIR

Reuti reuti at staff.uni-marburg.de
Thu Sep 13 16:46:26 BST 2007


Am 13.09.2007 um 17:15 schrieb Colin Thomas:

> Thanks for the suggestion.
>
> I have KEEP_ACTIVE=ALL in the mconf for a particular machine
>
> i.e.
>
> mailer                       /bin/mailx
> xterm                        /usr/openwin/bin/xterm
> qlogin_daemon                /usr/sbin/in.telnetd
> rlogin_daemon                /usr/sbin/in.rlogind
> exec_parameters              KEEP_ACTIVE=TRUE
>
> I then run qsh on ThisMachine
>
> qsub -q CADTEST at ThisMachine
>
> The temp directory is created, but when the qsh is exited, the temp
> directory is still being erased.
>
> Have I missed something ?

Mmh - seems the new local configuration isn't read in. Can you just  
edit the global configuration by removing a blank in any line (to  
change the file), then it should be read in (you can check this in / 
var/spool/sge/<your_node>/messages or you location for this file).

Is this worth to file an issue?

-- Reuti


> Best regards
>
> Colin Thomas
>
>
> -----Original Message-----
> From: Reuti [mailto:reuti at staff.uni-marburg.de]
> Sent: 13 September 2007 14:50
> To: users at gridengine.sunsource.net
> Subject: Re: [GE users] TMPDIR
>
> Hi,
>
> Am 13.09.2007 um 15:03 schrieb Colin Thomas:
>
>> Many thanks for your reply.
>>
>> Is KEEP_ACTIVE an execd parameter ? If so I can see how (via qmon) it
>> can be changed in the cluster configuration.
>>
>> So I "modify" a single machine, add KEEP_ACTIVE=1 to the
>> execd_parameters , click okay , but it then says that the "host
>> already
>> exists" even though I was modifying it :-(
>>
>> What is an alternative way of altering a machines's execd parameter
>> (not
>> through qmon).
>
> I would use the value TRUE instead. But the real reason is this:
>
> http://gridengine.sunsource.net/issues/show_bug.cgi?id=2080
>
> -- Reuti
>
>
>> Best regards
>>
>> Colin Thomas
>>
>> -----Original Message-----
>> From: Reuti [mailto:reuti at staff.uni-marburg.de]
>> Sent: 13 September 2007 13:37
>> To: users at gridengine.sunsource.net
>> Subject: Re: [GE users] TMPDIR
>>
>> Hi,
>>
>> Am 13.09.2007 um 14:03 schrieb Colin Thomas:
>>
>>> I have a question about TMPDIR.
>>>
>>> When job is started the TMPDIR is set to
>>>
>>> <temp dir from queue config>/<gridId>.<queue Name>
>>>
>>> We have a qsh job, which creates an xterm.
>>
>> how? Is it jumping out of the process tree - like started with & ?
>> You can try to set ENABLE_ADDGRP_KILL in the SGE configuration for
>> the execd_params so that the xterm is killed when the main job
>> completed.
>>
>> -- Reuti
>>
>> PS: There is the option KEEP_ACTIVE to avoid the removal, but this
>> way you would end up a) with many orphaned directories on the nodes
>> over time, and b) violating SGE's policy, as the xterm might still
>> generate load on the system but SGE will put already another job on
>> it.
>>
>> ...
>>
>>> The xterm is inheriting  the
>>> TMPDIR that the qsh set up. Then the qsh job completes (with the
>>> xterm
>>> still running), and the TMPDIR is removed. The xterm then has no
>>> TMPDIR
>>> to write to. This did start a conversation saying the the qsh job
>>> should
>>> have know that the xterm child process was still active, and so
>>> should
>>> not have cleaned up anyway..
>>>
>>> I have looked (and failed) to find a switch to disable the TMPDIR
>>> from
>>> being deleted : is there such a thing ?
>>>
>>> I did note some talk about in messages concerning the notify setting
>>> from the queue configuration (which is set to 60sec by default) but
>>> changing this does not seem to postpone the TMPDIR from being
>>> cleaned.
>>
>> PPS: Depends on the handling of the signal by the main job. If it
>> can't handle it, it will simply quit and tell SGE as a result that it
>> finished already. If you ignore the generated signal in the
>> jobscript, then during the grace period before being killed finally,
>> the TMPDIR should still exist.
>>
>>> I also tried a prolog script to try and set it to a value that I
>>> wanted,
>>> but this route also did not work.
>>>
>>> Any thoughts ? (we are 6.03u)
>>>
>>> Best regards
>>>
>>> Colin Thomas
>>>
>>>
>>
>>
>> .
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
>> For additional commands, e-mail: users-help at gridengine.sunsource.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
> For additional commands, e-mail: users-help at gridengine.sunsource.net
>
>
>
>  To report this email as spam click
> https://www.mailcontrol.com/sr/wQw0zmjPoHdJTZGyOCrrhg==
> yyWHfXXYSqjB79RLVo6vPFq4nRiFC! 
> liSPrGkOZ3KrsRrGRcietNIId7UBsuqLVIXemMXYLU
> gKs3DGazu7PV5EoF8b2JvztAPgoQxfcEX0kv7IZhQm9hOyRSOfEsg 
> +HNjoqPfnPERaxB9x8!
> PYkQfQTylaqnOcZZHjFaCqIZHvtLZRS1djMmiDe .
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
> For additional commands, e-mail: users-help at gridengine.sunsource.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
For additional commands, e-mail: users-help at gridengine.sunsource.net




More information about the gridengine-users mailing list