[torqueusers] ulimit in prologue

Nicolas Ferré nicolas.ferre at univ-provence.fr
Sat Jun 19 12:49:38 MDT 2010


Unfortunately, modifying the limit in .bashrc does not work. It simply
seems the .bashrc file is not sourced on the computing node. Actually,
in our cluster, a user shares its home directory between the login
node and the computing nodes through NFS.
I also tried to modify the mom_priv/config on a computing node, adding
something like !ulimit -l unlimited, but no way (after having restart
pbs_mom). About limits.conf, I already noticed it does not work.

Any other idea?

Nicolas Ferre'
Laboratoire Chimie Provence
Universite' de Provence



2010/6/19 George Wm Turner <turnerg at indiana.edu>:
>> > Another thing to look at maybe (apart from the pbs_mom startup
>> script) is /etc/security/limits.conf
>> > (and limits.d/*) if you have that on your system. Can't say I've
>> tried it myself though.
>
> The limits.conf doesn't work because that is usual applied by a pam
> module durning login. Since  pbs_mom is usually started by a boot
> script, the limits in limits.conf do not get applied.  The limits
> pbs_mom does have is what it inherited from init.  It's not unusual
> while debugging limit issues that when pbs_mom is started by hand
> things just work; yet, the next reboot, the problems return.  Not that
> when you start by hand, that pbs_mom inherits the limits of your
> process and you've gone through login and limits.conf apply.
>
> There are secondary issues which come into play with MPI programs; do
> your secondary tasks go through login (ssh) or are they started by the
> pbs_mom (e.g. Open MPI using TORQUE's TM mechanism)  In the end, you
> can put the limit commands in the users .bashrc file and each process
> started will inherit those limits.
>
> george wm turner
> high performance systems
> 812 855 5156
>
>
>
> On Jun 19, 2010, at 6:45 AM, Lawrence Lowe wrote:
>
>>> The "ulimit -l unlimited" I've put in torque prologue is ignored. Is
>>> there any reason for that ?
>>
>> hi, I guess the reason is that a ulimit is set for a process, and
>> inherited by its daughter processes, but the user job is run as a
>> different process and not a daughter of the prologue :-)
>>
>> Another thing to look at maybe (apart from the pbs_mom startup
>> script) is /etc/security/limits.conf (and limits.d/*) if you have
>> that on your system. Can't say I've tried it myself though.
>>
>> Lawrence Lowe
>>
>> Tel: 0121 414 4621    Fax: 0121 414 6709    Email: L.S.Lowe at bham.ac.uk
>>
>> On Sat, 19 Jun 2010, Wickliffe, Blake W wrote:
>>
>>> For what it is worth, we added that line to the startup script of
>>> pbs_mom.  Seems to work.
>>>
>>> Blake Wickliffe
>>> Saudi Aramco
>>> ENOD/CSYS/USG HPC Team
>>> (873-4417)
>>>
>>>
>>> -----Original Message-----
>>> From: torqueusers-bounces at supercluster.org [mailto:torqueusers-bounces at supercluster.org
>>> ] On Behalf Of Nicolas Ferré
>>> Sent: Saturday, June 19, 2010 10:20 AM
>>> To: Torque
>>> Subject: [torqueusers] ulimit in prologue
>>>
>>> Hi,
>>>
>>> The "ulimit -l unlimited" I've put in torque prologue is ignored. Is
>>> there any reason for that ?
>>>
>>> Regards,
>>>
>>> Nicolas Ferre'
>>> Laboratoire Chimie Provence
>>> Universite' de Provence
>>> _______________________________________________
>>> torqueusers mailing list
>>> torqueusers at supercluster.org
>>> http://www.supercluster.org/mailman/listinfo/torqueusers
>>>
>>> The contents of this email, including all related responses, files
>>> and attachments transmitted with it (collectively referred to as
>>> ÿÿthis Emailÿÿ), are intended solely for the use of the individual/
>>> entity to whom/which they are addressed, and may contain
>>> confidential and/or legally privileged information. This Email may
>>> not be disclosed or forwarded to anyone else without authorization
>>> from the originator of this Email. If you have received this Email
>>> in error, please notify the sender immediately and delete all
>>> copies from your system. Please note that the views or opinions
>>> presented in this Email are those of the author and may not
>>> necessarily represent those of Saudi Aramco. The recipient should
>>> check this Email and any attachments for the presence of any
>>> viruses. Saudi Aramco accepts no liability for any damage caused by
>>> any virus/error transmitted by this Email.
>>> _______________________________________________
>>> torqueusers mailing list
>>> torqueusers at supercluster.org
>>> http://www.supercluster.org/mailman/listinfo/torqueusers
>> _______________________________________________
>> torqueusers mailing list
>> torqueusers at supercluster.org
>> http://www.supercluster.org/mailman/listinfo/torqueusers
>
> _______________________________________________
> torqueusers mailing list
> torqueusers at supercluster.org
> http://www.supercluster.org/mailman/listinfo/torqueusers
>


More information about the torqueusers mailing list