Re: KDE and the compose key

["Jeremy C. Reed" <reed%reedmedia.net@localhost>]

On Wed, 12 Sep 2012, Sverre Froyen wrote:

> 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.

Yes, I consider it a problem.
http://mail-index.netbsd.org/netbsd-help/2006/01/17/0010.html

Others have reported same problem.

> 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"

See options(4) manual page.

> 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.

kern.maxfiles should work at boot time. You can raise it later. But it 
doesn't help to raise the limits of other running programs. I checked 
that by setting proc.389.rlimit.descriptors.hard (that is my sshd 
server) to a lower number and then doing a new login.  (YOu can try 
rebooting with the sysctl.conf setup or manually raise the 
proc.PID.rlimit.descriptors.hard for your login processes.

Note that kern.maxfiles is for all processes and the NOFILE is for 
per-process limits.