pkgsrc-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: KDE and the compose key
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
Home |
Main Index |
Thread Index |
Old Index