Ticket #11939 (new defect)
Notebook "ulimit -v" does not work
| Reported by: | jdemeyer | Owned by: | jason, mpatel, was |
|---|---|---|---|
| Priority: | critical | Milestone: | sage-5.11 |
| Component: | notebook | Keywords: | |
| Cc: | Work issues: | ||
| Report Upstream: | N/A | Reviewers: | |
| Authors: | Merged in: | ||
| Dependencies: | Stopgaps: |
Description (last modified by jdemeyer) (diff)
The ulimit -v argument does not do anything at all (I have not tested other ulimit options), neither locally nor remote. Both commands
notebook(ulimit="-v 1")
and
notebook(server_pool=["jdemeyer@localhost"], ulimit="-v 1")
don't seem to put any limit.
Change History
comment:2 follow-up: ↓ 3 Changed 20 months ago by ppurka
I looked at the code couple of months ago and what it does is baffling. It parses all the parameters and then recombines them and tries to call ulimit. No idea why it does so.
In my opinion, setting ulimit should be an argument to SAGE_ROOT/sage, i.e., SAGE_ROOT/local/bin/sage-sage. Then ulimit should be set by running ulimit <along with the options passed without parsing them> and then Sage or the Sage notebook should be launched. Since Sage or Sage nb will be running in the same shell, it will run with the ulimits that were set.
comment:3 in reply to: ↑ 2 Changed 20 months ago by jdemeyer
Replying to ppurka:
Since Sage or Sage nb will be running in the same shell, it will run with the ulimits that were set.
This is not true for remote notebook workers, so we need something more clever.
comment:4 Changed 20 months ago by leif
It seems at least your example (-v 1) yields a zero limit, since the value is first divided by 1000.0, then gets converted back to an int, and afterwards gets multiplied by 1000 again.
comment:5 Changed 20 months ago by ppurka
Even with all the conversions, I am pretty sure ulimit does not work. That's what brought down our servers on the first day of classes. Everyone had -v set to 2G and yet the Sage process of one person was allowed to run up 20G+ of memory, eating up all the available ram and swap.
comment:6 Changed 20 months ago by leif
You may try this (haven't tested the notebook at all):
-
sagenb/interfaces/expect.py
diff --git a/sagenb/interfaces/expect.py b/sagenb/interfaces/expect.py
a b 47 47 if process_limits: 48 48 u = '' 49 49 if process_limits.max_vmem is not None: 50 u += ' -v %s'%(int(process_limits.max_vmem )*1000)50 u += ' -v %s'%(int(process_limits.max_vmem*1000)) 51 51 if process_limits.max_cputime is not None: 52 52 u += ' -t %s'%(int(process_limits.max_cputime)) 53 53 if process_limits.max_processes is not None:
comment:7 Changed 20 months ago by ppurka
Oh, also you can check whether ulimit is set by running this from a worksheet:
import os
os.system("ulimit -a")
comment:8 Changed 20 months ago by leif
Hahahahaha!!!1!
def command(self):
return self._python
# TODO: The following simply doesn't work -- this is not a valid way to run
# ulimited. Also we should check if ulimit is available before even
# doing this.
return '&&'.join([x for x in [self._ulimit, self._python] if x])
(This is WorksheetProcess_ExpectImplementation.command().)
comment:9 Changed 20 months ago by jdemeyer
- Milestone sage-4.7.3 deleted
Milestone sage-4.7.3 deleted
comment:10 Changed 5 months ago by novoselt
- Milestone set to sage-5.7
In my experience the only working way to set limits is to edit the sage script to call ulimit if the username is "Sage worker". It is quite annoying to remember to do it between upgrades and in any case this is not what the documentation tells us to do...
