Re: KDE and the compose key

[Sverre Froyen <sverre%viewmark.com@localhost>]

On Wednesday 12 September 2012 06:53:22 Jeremy C. Reed wrote:
> On Tue, 11 Sep 2012, Sverre Froyen wrote:
> > BTW, what is the correct way of increasing the default soft limit for
> > NetBSD (in my case current)? It is is currenly set to 2048, which is
> > too small for running KDE with the Qt kqueue patches. I've tried to
> > uncomment the default login class in /etc/login.conf and set
> > openfiles-cur=4096 -- but that appears to no effect (I did run
> > cap_mkdb /etc/login.conf).
> 
> That probably didn't work because you attempted to set the -cur to a
> number greater than the -max limit.  Try setting the openfiles-max also
> or try setting it without the -cur suffix.  See ulimit -nH too.
> 
> By the way, I don't know if the KDE login honors login classes.
> 
> > I can work around it by adding a "ulimit -n 4096" to my .profile but
> > it seems there should be a way to change the system default.
> 
> I am also surprised that even using ~/.profile works; maybe because you
> are logging into to a shell first and then starting KDE?
> 
> For the system wide open files limit, see the sysctl kern.maxfiles.
> And see /etc/sysctl.conf.

Thanks for the hints. And yes, I am using a standard shell login.

Turns out the issue was "cap_mkdb /etc/login.conf" command. If the file 
/etc/login.conf.db exists, cap_mkdb reads that file (ignoring /etc/login.conf) 
and generates a new /etc/login.conf.db from the old /etc/login.conf.db. Seems 
to me this is counter intuitive, if not a bug. If I remove /etc/login.conf.db 
before running cap_mkdb, everything works as expected.

BTW, I also discovered that the kernel options MAXFILES determines the initial 
hard open file limit and NOFILE determines the soft limit. I can verify this 
using either "ulimit -aH" / "ulimit -aS" or "sysctl 
proc.curproc.rlimit.descriptors"

The sysctl interface suggests that there should be a way to set system 
defaults in /etc/sysctl.conf, but I have been unable to do so (probably 
because I cannot figure out which process ID to modify). kern.maxfiles also 
does not work, but that may be because I was attempting to increase the limit. 
Suggestions for a sysctl mechanism would be welcome.

Thanks,
Sverre