[GE users] TMPDIR

Reuti reuti at staff.uni-marburg.de
Fri Sep 14 08:36:10 BST 2007


Am 14.09.2007 um 09:02 schrieb Colin Thomas:

> I have just tried your suggestion re
>
> qconf -mconf global
>
> and removing blank lines.

So a message 'blabla at anywhere modified "global" in configuration  
list' appeard. Maybe you have to adjust also in the configuration:

loglevel                     log_info

to get the desired information of the loaded configuration in the  
messages file.

> I reran the
>
> qsub -q CADTEST at ThisMachine
>
> (where ThisMachine has exec_parameters              KEEP_ACTIVE=TRUE)

Typo? It's execd_param (missing d).

-- Reuti

>
> And still the directory is deleted.
>
> I have checked the messages file for ThisMachine, ad nothing has been
> added.
>
> Looks like a bug - where do I submit it as a bug ?
>
> Best regards
>
> Colin Thomas
>
> -----Original Message-----
> From: Reuti [mailto:reuti at staff.uni-marburg.de]
> Sent: 13 September 2007 16:46
> To: users at gridengine.sunsource.net
> Subject: Re: [GE users] TMPDIR
>
> 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
>
> ---------------------------------------------------------------------
> 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