kvm_open: kvm_getprocs: Cannot allocate memory

Z

zbroyar

Hi all,

When I try to start top I get the following error:

Code: 
kvm_open: kvm_getprocs: Cannot allocate memory
top: Out of memory.

Looks like similar problem affecting my ps too, b/c because ps axuw gives an empty list.

Any hints would be greatly appreciated.
 
Programs like ps(1) and top(1) will fail to work until the kernel and source code versions are the same. For rebuilding both programs, the recommended way is 'make buildworld'. Take a look to Handbook section 25.7, and follow described steps.
 
Solved.

I tracked the problem down to a sysctl() call in kvm_getprocs() which returned ENOMEM because locking the buffer oldp caused the process to exceed its per-process locked memory limit. This limit was set to 64K while the data was more than 100K. Editing of /etc/login.conf with following cap_mkdb login.conf and relogin solved the problem.
 
Use defaults setting login.conf to avoid problems. Every time that libkvm (see libkvm man pages) API/ABI suffers changes needs to rebuild ps(1), top(1), systat(1), and possibly other programs, which is why a buildworld is usually recommended.

Anyway, you can rebuild individually without doing buildworld:
Code: 
# cd /usr/src/usr.bin/top && make obj && make depend && make && make install
# cd /usr/src/bin/ps && make obj && make depend && make && make install
 
I appreciate your suggestions, and I did rebuild top and ps a few times during negotiations with this problem. But nothing happened. Can you check your login.conf for a value of memorylocked in default class?

I think I made a mistake while mergemaster -i and didn't update login.conf appropriately.
 
zbroyar said:
I appreciate your suggestions, and I did rebuild top and ps few times during negotiations with this problem. But nothing happened. Can you check your login.conf for a value of memorylocked in default class?

I think I made a mistake while mergemaster -i and didn't update login.conf appropriately.
Click to expand...
See introduced changes by MFC r244383.

Reverting last changes in login.conf "default" class, as you did solves the problem, but is better set value to unlimited:
Code: 
default:\
        :memorylocked=unlimited:\

Moreover, init(8) uses "daemon" class to run /etc/rc, last change been established limit to 64Mb should not causes failure of mlockall(2). If happens and some daemon be complaint, change to unlimited too.

After, run cap_mkdb(1) to rebuild the login database:

# cap_mkdb /etc/login.conf

As root using chpass(1), set 'Class: default' in /etc/master.passwd:

# chpass user
 
You must log in or register to reply here.
Back
Top