Expose more limits in ulimit

[septatrix]

• Version: 3.3.1
• OS: Fedora 35, Kernel Version: 5.16.12-200.fc35.x86_64

The bash builtin ulimit (which is also the fallback/command ulimit) exposes many more limits which fish does not show. Some of them might be unique to bash and others seem to have a reason for excluding -p the are quite a few which are missing. The list seems to be eipqrsx

~ $ bash -c "type ulimit && ulimit -a"
ulimit is a shell builtin
real-time non-blocking time  (microseconds, -R) unlimited
core file size              (blocks, -c) unlimited
data seg size               (kbytes, -d) unlimited
scheduling priority                 (-e) 0
file size                   (blocks, -f) unlimited
pending signals                     (-i) 95584
max locked memory           (kbytes, -l) 8192
max memory size             (kbytes, -m) unlimited
open files                          (-n) 1024
pipe size                (512 bytes, -p) 8
POSIX message queues         (bytes, -q) 819200
real-time priority                  (-r) 0
stack size                  (kbytes, -s) 8192
cpu time                   (seconds, -t) unlimited
max user processes                  (-u) 95584
virtual memory              (kbytes, -v) unlimited
file locks                          (-x) unlimited
~ $ type ulimit && ulimit -a
ulimit is a builtin
Maximum size of core files created                           (kB, -c) unlimited
Maximum size of a process’s data segment                     (kB, -d) unlimited
Maximum size of files created by the shell                   (kB, -f) unlimited
Maximum size that may be locked into memory                  (kB, -l) 8192
Maximum resident set size                                    (kB, -m) unlimited
Maximum number of open file descriptors                          (-n) 1024
Maximum stack size                                           (kB, -s) 8192
Maximum amount of cpu time in seconds                   (seconds, -t) unlimited
Maximum number of processes available to a single user           (-u) 95584
Maximum amount of virtual memory available to the shell      (kB, -v) unlimited

[faho]

This isn't something the shell should care about, to be honest. It's awkward platform-specific guff that's only in the shell because that's where it's been placed historically.

Very very few people even care about the ulimit we do have. I would be entirely okay with removing it.

So I'm rejecting this.

[septatrix]

This isn't something the shell should care about, to be honest. It's awkward platform-specific guff that's only in the shell because that's where it's been placed historically.

For fetching the limits I agree and would be fine with simply returning the content of /proc/self/limits. However the reason why it is a shell builtin is because it has to be. If one wants to set limits for new processes it cannot be done by a separate executable because it cannot set limits on a parent process.

[zanchey]

Actually, on Linux, it doesn't have to - prlimit(1) alters other processes using prlimit(3) (this is a Linux-specific system call).

I think it's reasonable to add these to the existing builtin - it's a tiny patch.

[zanchey]

RLIMIT_NICE (since Linux 2.6.12, but see BUGS below)

This specifies a ceiling to which the process's nice value can be raised using setpriority(2) or nice(2). The actual ceiling for the nice value is calculated as 20 - rlim_cur. The useful range for this limit is thus from 1 (corresponding to a nice value of 19) to 40 (corresponding to a nice value of -20). This unusual choice of range was necessary because negative numbers cannot be specified as resource limit values, since they typically have special meanings. For example, RLIM_INFINITY typically is the same as -1. For more detail on the nice value, see sched(7).

🤯

[septatrix]

Actually, on Linux, it doesn't have to - prlimit(1) alters other processes using prlimit(3) (this is a Linux-specific system call).

Huh neat. I did not know that call hat a corresponding executable.

I think it's reasonable to add these to the existing builtin - it's a tiny patch.

Yes. Simply using prlimit would also be cumbersome if one wants to set limits for a whole shell session/script without using prlimit to spawn a subshell