Re: limits.conf/stacksize doesn't seem to work?
On Sat, Jul 16, 2022 at 1:32 AM Mark Johnston wrote: > On Fri, Jul 15, 2022 at 05:26:09PM -0500, Larry Rosenman wrote: > > On 07/15/2022 5:24 pm, Mark Johnston wrote: > > > On Fri, Jul 15, 2022 at 05:21:27PM -0500, Larry Rosenman wrote: > > >> On 07/15/2022 5:18 pm, Mark Johnston wrote: > > >> > On Fri, Jul 15, 2022 at 05:04:18PM -0500, Larry Rosenman wrote: > > >> >> I'm using the following kernel config: > > >> >> [...] > > >> >> and the following login.conf: > > >> >> [...] > > >> >> bacula_dir:\ > > >> >> :stacksize-max=68719476736:\ > > >> >> :stacksize-cur=68719476736:\ > > >> >> :tc=daemon: > > >> >> [...] > > >> >> I've updated my (ler) password entry to reference bacula_dir: > > >> >> ler::1001:1001:bacula_dir:0:0:Larry > > >> >> Rosenman:/home/ler:/usr/local/bin/zsh > > >> >> > > >> >> > > >> >> when I ssh in, the stacklimit is still: > > >> >> ❯ ulimit -H -s > > >> >> 2097152 > > >> > > > >> > What is the value of the kern.maxssiz sysctl on this system? > > >> > > > >> >> ler in borg in sys/amd64/conf on > ler/freebsd-main-changes:main on > > >> >> ☁️ (us-east-1) > > >> >> ❯ ulimit -S -s > > >> >> 2097152 > > >> >> > > >> >> ler in borg in sys/amd64/conf on > ler/freebsd-main-changes:main on > > >> >> ☁️ (us-east-1) > > >> >> ❯ > > >> >> > > >> >> Where does this number come from? What am I missing here? > > >> > > > >> > The stack limit cannot be set to an arbitrarily large number. It > will > > >> > silently be clamped to maxssiz. > > >> > > >> ❯ sysctl kern.maxssiz > > >> kern.maxssiz: 2147483648 > > > > > > Then what you're seeing is expected. The kernel is clamping the stack > > > segment limit to 2GB. > > > > I assume this is the default for MAXSSIZ? and if I change that in the > > kernel config, it will > > allow bigger? Where is this default defined? > > The default value is platform dependent. On amd64 it's 512MB, so I'm > not sure where your value is coming from. --- > It's defined in a header. > You can set it in the kernel configuration, or as a tunable or sysctl. > > --- My opinion is that , there is some one ( or more ) constant(s) defined elsewhere , because setting MAXSSIZ is NOT WORKING when it is larger than the "unknown" default value ... With my best wishes for all , Mehmet Erol Sanliturk
Re: limits.conf/stacksize doesn't seem to work?
On 07/15/2022 5:32 pm, Mark Johnston wrote: On Fri, Jul 15, 2022 at 05:26:09PM -0500, Larry Rosenman wrote: On 07/15/2022 5:24 pm, Mark Johnston wrote: > On Fri, Jul 15, 2022 at 05:21:27PM -0500, Larry Rosenman wrote: >> On 07/15/2022 5:18 pm, Mark Johnston wrote: >> > On Fri, Jul 15, 2022 at 05:04:18PM -0500, Larry Rosenman wrote: >> >> I'm using the following kernel config: >> >> [...] >> >> and the following login.conf: >> >> [...] >> >> bacula_dir:\ >> >> :stacksize-max=68719476736:\ >> >> :stacksize-cur=68719476736:\ >> >> :tc=daemon: >> >> [...] >> >> I've updated my (ler) password entry to reference bacula_dir: >> >> ler::1001:1001:bacula_dir:0:0:Larry >> >> Rosenman:/home/ler:/usr/local/bin/zsh >> >> >> >> >> >> when I ssh in, the stacklimit is still: >> >> ❯ ulimit -H -s >> >> 2097152 >> > >> > What is the value of the kern.maxssiz sysctl on this system? >> > >> >> ler in borg in sys/amd64/conf on ler/freebsd-main-changes:main on >> >> ☁️ (us-east-1) >> >> ❯ ulimit -S -s >> >> 2097152 >> >> >> >> ler in borg in sys/amd64/conf on ler/freebsd-main-changes:main on >> >> ☁️ (us-east-1) >> >> ❯ >> >> >> >> Where does this number come from? What am I missing here? >> > >> > The stack limit cannot be set to an arbitrarily large number. It will >> > silently be clamped to maxssiz. >> >> ❯ sysctl kern.maxssiz >> kern.maxssiz: 2147483648 > > Then what you're seeing is expected. The kernel is clamping the stack > segment limit to 2GB. I assume this is the default for MAXSSIZ? and if I change that in the kernel config, it will allow bigger? Where is this default defined? The default value is platform dependent. On amd64 it's 512MB, so I'm not sure where your value is coming from. It's defined in a header. You can set it in the kernel configuration, or as a tunable or sysctl. ok, so I had (back when, heaven only knows) set it in /boot/loader.conf: kern.maxssiz="2147483648" thank you. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
Re: limits.conf/stacksize doesn't seem to work?
On Fri, Jul 15, 2022 at 05:26:09PM -0500, Larry Rosenman wrote: > On 07/15/2022 5:24 pm, Mark Johnston wrote: > > On Fri, Jul 15, 2022 at 05:21:27PM -0500, Larry Rosenman wrote: > >> On 07/15/2022 5:18 pm, Mark Johnston wrote: > >> > On Fri, Jul 15, 2022 at 05:04:18PM -0500, Larry Rosenman wrote: > >> >> I'm using the following kernel config: > >> >> [...] > >> >> and the following login.conf: > >> >> [...] > >> >> bacula_dir:\ > >> >> :stacksize-max=68719476736:\ > >> >> :stacksize-cur=68719476736:\ > >> >> :tc=daemon: > >> >> [...] > >> >> I've updated my (ler) password entry to reference bacula_dir: > >> >> ler::1001:1001:bacula_dir:0:0:Larry > >> >> Rosenman:/home/ler:/usr/local/bin/zsh > >> >> > >> >> > >> >> when I ssh in, the stacklimit is still: > >> >> ❯ ulimit -H -s > >> >> 2097152 > >> > > >> > What is the value of the kern.maxssiz sysctl on this system? > >> > > >> >> ler in borg in sys/amd64/conf on ler/freebsd-main-changes:main on > >> >> ☁️ (us-east-1) > >> >> ❯ ulimit -S -s > >> >> 2097152 > >> >> > >> >> ler in borg in sys/amd64/conf on ler/freebsd-main-changes:main on > >> >> ☁️ (us-east-1) > >> >> ❯ > >> >> > >> >> Where does this number come from? What am I missing here? > >> > > >> > The stack limit cannot be set to an arbitrarily large number. It will > >> > silently be clamped to maxssiz. > >> > >> ❯ sysctl kern.maxssiz > >> kern.maxssiz: 2147483648 > > > > Then what you're seeing is expected. The kernel is clamping the stack > > segment limit to 2GB. > > I assume this is the default for MAXSSIZ? and if I change that in the > kernel config, it will > allow bigger? Where is this default defined? The default value is platform dependent. On amd64 it's 512MB, so I'm not sure where your value is coming from. It's defined in a header. You can set it in the kernel configuration, or as a tunable or sysctl.
Re: limits.conf/stacksize doesn't seem to work?
On 07/15/2022 5:24 pm, Mark Johnston wrote: On Fri, Jul 15, 2022 at 05:21:27PM -0500, Larry Rosenman wrote: On 07/15/2022 5:18 pm, Mark Johnston wrote: > On Fri, Jul 15, 2022 at 05:04:18PM -0500, Larry Rosenman wrote: >> I'm using the following kernel config: >> [...] >> and the following login.conf: >> [...] >> bacula_dir:\ >>:stacksize-max=68719476736:\ >>:stacksize-cur=68719476736:\ >>:tc=daemon: >> [...] >> I've updated my (ler) password entry to reference bacula_dir: >> ler::1001:1001:bacula_dir:0:0:Larry >> Rosenman:/home/ler:/usr/local/bin/zsh >> >> >> when I ssh in, the stacklimit is still: >> ❯ ulimit -H -s >> 2097152 > > What is the value of the kern.maxssiz sysctl on this system? > >> ler in borg in sys/amd64/conf on ler/freebsd-main-changes:main on >> ☁️ (us-east-1) >> ❯ ulimit -S -s >> 2097152 >> >> ler in borg in sys/amd64/conf on ler/freebsd-main-changes:main on >> ☁️ (us-east-1) >> ❯ >> >> Where does this number come from? What am I missing here? > > The stack limit cannot be set to an arbitrarily large number. It will > silently be clamped to maxssiz. ❯ sysctl kern.maxssiz kern.maxssiz: 2147483648 Then what you're seeing is expected. The kernel is clamping the stack segment limit to 2GB. I assume this is the default for MAXSSIZ? and if I change that in the kernel config, it will allow bigger? Where is this default defined? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
Re: limits.conf/stacksize doesn't seem to work?
On Fri, Jul 15, 2022 at 05:21:27PM -0500, Larry Rosenman wrote: > On 07/15/2022 5:18 pm, Mark Johnston wrote: > > On Fri, Jul 15, 2022 at 05:04:18PM -0500, Larry Rosenman wrote: > >> I'm using the following kernel config: > >> [...] > >> and the following login.conf: > >> [...] > >> bacula_dir:\ > >>:stacksize-max=68719476736:\ > >>:stacksize-cur=68719476736:\ > >>:tc=daemon: > >> [...] > >> I've updated my (ler) password entry to reference bacula_dir: > >> ler::1001:1001:bacula_dir:0:0:Larry > >> Rosenman:/home/ler:/usr/local/bin/zsh > >> > >> > >> when I ssh in, the stacklimit is still: > >> ❯ ulimit -H -s > >> 2097152 > > > > What is the value of the kern.maxssiz sysctl on this system? > > > >> ler in borg in sys/amd64/conf on ler/freebsd-main-changes:main on > >> ☁️ (us-east-1) > >> ❯ ulimit -S -s > >> 2097152 > >> > >> ler in borg in sys/amd64/conf on ler/freebsd-main-changes:main on > >> ☁️ (us-east-1) > >> ❯ > >> > >> Where does this number come from? What am I missing here? > > > > The stack limit cannot be set to an arbitrarily large number. It will > > silently be clamped to maxssiz. > > ❯ sysctl kern.maxssiz > kern.maxssiz: 2147483648 Then what you're seeing is expected. The kernel is clamping the stack segment limit to 2GB.
Re: limits.conf/stacksize doesn't seem to work?
On 07/15/2022 5:18 pm, Mark Johnston wrote: On Fri, Jul 15, 2022 at 05:04:18PM -0500, Larry Rosenman wrote: I'm using the following kernel config: [...] and the following login.conf: [...] bacula_dir:\ :stacksize-max=68719476736:\ :stacksize-cur=68719476736:\ :tc=daemon: [...] I've updated my (ler) password entry to reference bacula_dir: ler::1001:1001:bacula_dir:0:0:Larry Rosenman:/home/ler:/usr/local/bin/zsh when I ssh in, the stacklimit is still: ❯ ulimit -H -s 2097152 What is the value of the kern.maxssiz sysctl on this system? ler in borg in sys/amd64/conf on ler/freebsd-main-changes:main on ☁️ (us-east-1) ❯ ulimit -S -s 2097152 ler in borg in sys/amd64/conf on ler/freebsd-main-changes:main on ☁️ (us-east-1) ❯ Where does this number come from? What am I missing here? The stack limit cannot be set to an arbitrarily large number. It will silently be clamped to maxssiz. ❯ sysctl kern.maxssiz kern.maxssiz: 2147483648 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
Re: limits.conf/stacksize doesn't seem to work?
On Fri, Jul 15, 2022 at 05:04:18PM -0500, Larry Rosenman wrote: > I'm using the following kernel config: > [...] > and the following login.conf: > [...] > bacula_dir:\ > :stacksize-max=68719476736:\ > :stacksize-cur=68719476736:\ > :tc=daemon: > [...] > I've updated my (ler) password entry to reference bacula_dir: > ler::1001:1001:bacula_dir:0:0:Larry > Rosenman:/home/ler:/usr/local/bin/zsh > > > when I ssh in, the stacklimit is still: > ❯ ulimit -H -s > 2097152 What is the value of the kern.maxssiz sysctl on this system? > ler in borg in sys/amd64/conf on ler/freebsd-main-changes:main on > ☁️ (us-east-1) > ❯ ulimit -S -s > 2097152 > > ler in borg in sys/amd64/conf on ler/freebsd-main-changes:main on > ☁️ (us-east-1) > ❯ > > Where does this number come from? What am I missing here? The stack limit cannot be set to an arbitrarily large number. It will silently be clamped to maxssiz.
limits.conf/stacksize doesn't seem to work?
I'm using the following kernel config: ❯ cat LER-MINIMAL # LER-MINIMAL -- kernel config based on MINIMAL include MINIMAL ident LER-MINIMAL nooptions WITNESS # Enable checks to detect deadlocks and cycles nooptions WITNESS_SKIPSPIN# Don't run witness on spinlocks for speed options KDB_UNATTENDED #optionsDEBUG_MEMGUARD #optionsDEBUG_REDZONE makeoptions WITH_EXTRA_TCP_STACKS=1 options TCPHPTS device mfi options TCP_RFC7413 # Kernel dump features. options EKCD# Support for encrypted kernel dumps options GZIO# gzip-compressed kernel and user dumps options ZSTDIO # zstd-compressed kernel and user dumps options NETDUMP # netdump(4) client support # ipsec support options IPSEC_SUPPORT device crypto #netgraph debug options NETGRAPH_DEBUG #tcp ratelimit options RATELIMIT ## INVARIANTS options INVARIANT_SUPPORT options INVARIANTS ler in borg in sys/amd64/conf on ler/freebsd-main-changes:main on ☁️ (us-east-1) ❯ and the following login.conf: ❯ cat /etc/login.conf # login.conf - login class capabilities database. # # Remember to rebuild the database after each change to this file: # # cap_mkdb /etc/login.conf # # This file controls resource limits, accounting limits and # default user environment settings. # # $FreeBSD$ # # Default settings effectively disable resource limits, see the # examples below for a starting point to enable them. # defaults # These settings are used by login(1) by default for classless users # Note that entries like "cputime" set both "cputime-cur" and "cputime-max" # # Note that since a colon ':' is used to separate capability entries, # a \c escape sequence must be used to embed a literal colon in the # value or name of a capability (see the ``CGETNUM AND CGETSTR SYNTAX # AND SEMANTICS'' section of getcap(3) for more escape sequences). default:\ :passwd_format=sha512:\ :copyright=/etc/COPYRIGHT:\ :welcome=/var/run/motd:\ :setenv=BLOCKSIZE=K:\ :mail=/var/mail/$:\ :path=/sbin /bin /usr/sbin /usr/bin /usr/local/sbin /usr/local/bin ~/bin:\ :nologin=/var/run/nologin:\ :cputime=unlimited:\ :datasize=unlimited:\ :stacksize=unlimited:\ :memorylocked=64K:\ :memoryuse=unlimited:\ :filesize=unlimited:\ :coredumpsize=unlimited:\ :openfiles=unlimited:\ :maxproc=unlimited:\ :sbsize=unlimited:\ :vmemoryuse=unlimited:\ :swapuse=unlimited:\ :pseudoterminals=unlimited:\ :kqueues=unlimited:\ :umtxp=unlimited:\ :priority=0:\ :ignoretime@:\ :umask=022:\ :charset=UTF-8:\ :lang=C.UTF-8: # # A collection of common class names - forward them all to 'default' # (login would normally do this anyway, but having a class name # here suppresses the diagnostic) # standard:\ :tc=default: xuser:\ :tc=default: staff:\ :tc=default: # This PATH may be clobbered by individual applications. Notably, by default, # rc(8), service(8), and cron(8) will all override it with a default PATH that # may not include /usr/local/sbin and /usr/local/bin when starting services or # jobs. daemon:\ :path=/sbin /bin /usr/sbin /usr/bin /usr/local/sbin /usr/local/bin:\ :mail@:\ :memorylocked=128M:\ :tc=default: news:\ :tc=default: dialer:\ :tc=default: # # Root can always login # # N.B. login_getpwclass(3) will use this entry for the root account, # in preference to 'default'. root:\ :ignorenologin:\ :memorylocked=unlimited:\ :tc=default: # # Russian Users Accounts. Setup proper environment variables. # russian|Russian Users Accounts:\ :charset=UTF-8:\ :lang=ru_RU.UTF-8:\ :tc=default: bacula_dir:\ :stacksize-max=68719476736:\ :stacksize-cur=68719476736:\ :tc=daemon: ## ## ## ## Example entries ## ## ## ## Example defaults ## These settings are used by login(1) by default for classless users ## Note that entries like "cputime" set both "cputime-cur" and "cputime-max" # #default:\ # :cputime=infinity:\ # :datasize-cur=22M:\ # :stacksize-cur=8M:\ # :memorylocked-cur=10M:\ # :memoryuse-cur=30M:\ # :filesize=infinity:\ # :coredumpsize=infinity:\ # :maxproc-cur=64:\ # :openfiles-cur=64:\ # :priority=0:\ # :requirehome@:\ # :umask=022:\ #
