Why does the following way not change core file limit size?

Question

To solve the problem in https://unix.stackexchange.com/a/446428/674, I followed https://stackoverflow.com/a/17483998/156458, but it doesn't set core file limit size?

$ sudo sh -c "ulimit -c 1024 && exec su t"

$ ulimit -c
0

1. Does this way change the core file limit size temporarily just for the current shell, or permanently for all the shells of all the users or the current user?

2. Update: The original post https://stackoverflow.com/a/17483998/156458 and https://unix.stackexchange.com/a/238413/674 and https://unix.stackexchange.com/a/169035/674 all recommended using sudo sh -c "ulimit -c 1024 && exec su $LOGNAME". But both ulimit -c 1024 and exec su $LOGNAME" only affects the shell created by sudo, so what is the purpose of the command? exec su $LOGNAME" also doesn't do anything meaningful to make use of the changed limit.

---

Note: I am focusing on why the above way doesn't work, although there are other ways to get around the problem:

1. I should put the command which uses the new limit value inside the shell executed by sudo

   e.g.

   $ sudo sh -c "ulimit -c 1024 && sleep 100"
   ^\Quit
   $ ls
   core
   

2. I could also try to modify /etc/security/limits.conf.

Answer 1

According to the manpage, ulimit "provides control over the resources available to the shell and to processes started by it". So the ulimit value is valid for the current shell.

You are invoking ulimit in a subshell, and when it terminates you're back to the default ulimit value.

[root@centos7 ~]# ulimit -c
0
[root@centos7 ~]# ulimit -c 1024
[root@centos7 ~]# ulimit -c
1024

Answer 2

The ulimit command works for the shell that calls it and for it's descendants.

The command su will have the limit you did set up. The parent shell is not affected.

Answer 3

I am very confused and wonder if I am missing something

I think you are missing (or not recognizing) /etc/security/limits.conf Here is the template from Suse Linux Enterprise Server 11.4, and also how I globally set the stacksize limit to unlimited versus the default 8KB.

# /etc/security/limits.conf
#
#Each line describes a limit for a user in the form:
#
#<domain>        <type>  <item>  <value>
#
#Where:
#<domain> can be:
#        - an user name
#        - a group name, with @group syntax
#        - the wildcard *, for default entry
#        - the wildcard %, can be also used with %group syntax,
#                 for maxlogin limit
#
#<type> can have the two values:
#        - "soft" for enforcing the soft limits
#        - "hard" for enforcing hard limits
#
#<item> can be one of the following:
#        - core - limits the core file size (KB)
#        - data - max data size (KB)
#        - fsize - maximum filesize (KB)
#        - memlock - max locked-in-memory address space (KB)
#        - nofile - max number of open files
#        - rss - max resident set size (KB)
#        - stack - max stack size (KB)
#        - cpu - max CPU time (MIN)
#        - nproc - max number of processes
#        - as - address space limit (KB)
#        - maxlogins - max number of logins for this user
#        - maxsyslogins - max number of logins on the system
#        - priority - the priority to run user process with
#        - locks - max number of file locks the user can hold
#        - sigpending - max number of pending signals
#        - msgqueue - max memory used by POSIX message queues (bytes)
#        - nice - max nice priority allowed to raise to values: [-20, 19]
#        - rtprio - max realtime priority
#
*       hard    stack   unlimited
*       soft    stack   unlimited
*       hard    nofile  100000
*       soft    nofile  100000

This is from SLES, the limits.conf name and location might be different depending on your distribution of linux. Setting the values here will be global and be in effect for everything/everyone rather than using ulimit which would be limited to the scope of the shell window as was described.

Be forwarned, setting some items improperly can prevent you from logging into your system

Answer 4

I would like to address the part:

https://stackoverflow.com/a/17483998/156458, https://unix.stackexchange.com/a/238413/674 and https://unix.stackexchange.com/a/169035/674 all recommended using sudo sh -c "ulimit -c 1024 && exec su $LOGNAME". But both ulimit -c 1024 and exec su $LOGNAME" only affects the shell created by sudo, so what is the purpose of the command? exec su $LOGNAME" also doesn't do anything meaningful to make use of the changed limit. I am very confused and wonder if I am missing something.

I did some experiments, and found that after running

sudo sh -c "ulimit -c 1024 && exec su $LOGNAME"

• ulimit -c 1024 indeed modify the limit values, but only within the shell under sudo under the original shell;

• exec su $LOGNAME" will give me a shell under su under sudo under the original shell, and su $LOGNAME" resets the limits to the default values for user $LOGNAME.

So the command suggested by the links don't work.

for core file size:

$ ulimit -c -H; ulimit -c;                                                                                                                                                        
unlimited
0
$ ulimit -c 1024
$ ulimit -c -H; ulimit -c;                                                                                                                                                        
1024
1024
$ ulimit -c 10000
bash: ulimit: core file size: cannot modify limit: Operation not permitted
$ sudo sh -c "ulimit -c 10000 && ulimit -c -H && ulimit -c && exec su $LOGNAME"
[sudo] password for t:
10000
10000
$ ulimit -c -H; ulimit -c;                                                                                                                                                        
unlimited
0

$ ~/bin/get-ancestry-processes.sh
systemd,1 splash
  └─lxterminal,1242,t
      └─bash,22778
          └─sudo,22800,root sh -c ulimit -c 10000 && ulimit -c -H && ulimit -c && exec su t
              └─su,22802 t
                  └─bash,22803,t
                      └─get-ancestry-pr,22819 /home/t/bin/get-ancestry-processes.sh
                          └─pstree,22820 -G -a -s -l -p -u 22819

for number of opened files, to redo the experiment at https://unix.stackexchange.com/a/238413/674, but with a different limit value to set to

$ ulimit -n -H; ulimit -n;                                                                                                                                                        
1048576
1024
$ ulimit -n 512
$ ulimit -n -H; ulimit -n;                                                                                                                                                        
512
512
$ ulimit -n 10000
bash: ulimit: open files: cannot modify limit: Operation not permitted
$ sudo sh -c "ulimit -n 10000 && ulimit -n -H && ulimit -n && exec su $LOGNAME"
10000
10000
$ ulimit -n -H; ulimit -n                                                                                                                                                         
1048576
1024

Answer 5

Your own answer now contains the information that would have been needed in the question already:

Your system has an unusual setup.

On Solaris, you have the following limits and the POSIX set of resources:

LC_ALL=C ulimit -aHS
-t: time(seconds) unlimited:unlimited
-f: file(blocks) unlimited:unlimited
-d: data(kbytes) unlimited:unlimited
-s: stack(kbytes) 10240:unlimited
-c: coredump(blocks) unlimited:unlimited
-n: nofiles(descriptors) 256:65536
-v: memory(kbytes) unlimited:unlimited

On Linux you have the following typical limits:

ulimit -aSH
-t: time(seconds) unlimited:unlimited
-f: file(blocks) unlimited:unlimited
-d: data(kbytes) unlimited:unlimited
-s: stack(kbytes) 8192:unlimited
-c: coredump(blocks) 0:unlimited
-m: memoryuse(kbytes) unlimited:unlimited
-u: processes(count) 26633:26633
-n: nofiles(descriptors) 1024:1048576
-l: memlock(kbytes) 64:64
-M: addressspace(kbytes) unlimited:unlimited
-L: locks(count) unlimited:unlimited
-i: sigpending(count) 26633:26633
-q: messagequeues(count) 819200:819200
-e: schedpriority(nice) 0:0
-r: rtpriority(nice) 0:0
-R: rttime(usec) unlimited:unlimited

As you see, the hard limit is much bigger than yours. This is the reason why nobody could understand your problems.

Since an ordinary user is allowed to raise the soft limits to the hard limits, the request in your question would not need root privileges.