Re: firefox and maxfiles and rlimit.descriptors

[tlaronde%polynum.com@localhost]

On Sat, Nov 14, 2020 at 10:59:15PM +0000, Michael van Elst wrote:
> tlaronde%polynum.com@localhost writes:
> 
> >> >But how to increase proc.curproc.rlimit.descriptors.{hard,soft}?
> 
> >But this is the problem: ulimit -n doesn't accept it either. So I
> >concluded that the limit set by the kernel imposes, logically, a limit.
> 
> The hard limit is limited by the kernel limit.
> The soft limit is limited by the hard limit
> 
> only root can raise the hard limit. For some reason, trying to
> exceed the kernel limit is silently ignored.
> 
> E.g.:
> 
> $ ulimit -Hn
> 1772
> $ ulimit -Sn
> 1024
> $ ulimit -Sn 1772
> $ ulimit -Sn
> 1772
> $ ulimit -Sn 1773
> ulimit: error setting limit (Invalid argument)
> $ ulimit -Hn 2000
> ulimit: error setting limit (Operation not permitted)
> 
> 
> # sysctl -n kern.maxfiles
> 1772
> # ulimit -Hn
> 1772
> # ulimit -Hn 2000
> # ulimit -Hn
> 1772
> 
> # sysctl -w kern.maxfiles=5000
> kern.maxfiles: 1772 -> 5000
> # ulimit -Hn
> 1772
> # ulimit -Hn 2000
> # ulimit -Hn
> 2000
> # ulimit -Sn
> 1772
> # ulimit -Sn 2000
> # ulimit -Sn
> 2000
> # ulimit -Sn 2001
> ulimit: error setting limit (Invalid argument)
> 
> 
> Since limits are inherited, changing the kernel limit doesn't do
> anything unless you run a root process that raises the limit. Not
> even new logins will help.
> 
> You could:
> 
> - configure /etc/login.conf with explicit limits
>   a new login should then set the new limits.
>   But this doesn't necessarily apply to graphical logins.
> 
> - set a new hard limit for the init process like:
>   sysctl -w proc.1.rlimit.descriptors.hard=2000
>   And then make init spawn a new tty session (already running
>   getty processes still have the old limit).
> 
> To get this on startup, it's not sufficient to set kern.maxfiles
> in /etc/sysctl.conf. You need to set limits for proc.1 and for
> the shell that runs the rc scripts. This can be done with a sourced
> rc script.
> 
> >And:
> >sysctl -a|grep descriptors
> >only return proc.curproc...
> 
> Yes, the proc.$pid entries are hidden. Just try something like: sysctl proc.1
> 

Thank you to have taken the time to answer thoroughly!

Best,
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
                       http://www.sbfa.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C