Ticket #11939 (new defect)

Opened 20 months ago

Last modified 5 months ago

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:1 Changed 20 months ago by jdemeyer

  • Description modified (diff)

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  
    4747        if process_limits: 
    4848            u = '' 
    4949            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)) 
    5151            if process_limits.max_cputime is not None: 
    5252                u += ' -t %s'%(int(process_limits.max_cputime)) 
    5353            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...

Note: See TracTickets for help on using tickets.