nproc
Hi all, I have some questions about kernel calculations and number of processes. First, the specs: Rhel 5 running 2.6.18-238.el5 My first question is, does anyone know how nproc is calculated? I have seen some issues lately where the limits.conf hard limit is imposed, but the user hasn't exceeded the number of processes. The number of processes on the box is also reported as being abnormally high in newer kernels because every kernel processes is run on a per-core basis: root 669 0.0 0.0 0 0 ?S 07:28 0:00 [kblockd/0] root 670 0.0 0.0 0 0 ?S 07:28 0:00 [kblockd/1] root 671 0.0 0.0 0 0 ?S 07:28 0:00 [kblockd/2] root 672 0.0 0.0 0 0 ?S 07:28 0:00 [kblockd/3] root 673 0.0 0.0 0 0 ?S 07:28 0:00 [kblockd/4] root 674 0.0 0.0 0 0 ?S 07:28 0:00 [kblockd/5] root 675 0.0 0.0 0 0 ?S 07:28 0:00 [kblockd/6] root 676 0.0 0.0 0 0 ?S 07:28 0:00 [kblockd/7] root 677 0.0 0.0 0 0 ?S 07:28 0:00 [kblockd/8] root 678 0.0 0.0 0 0 ?S 07:28 0:00 [kblockd/9] root 679 0.0 0.0 0 0 ?S 07:28 0:00 [kblockd/10] root 680 0.0 0.0 0 0 ?S 07:28 0:00 [kblockd/11] root 681 0.0 0.0 0 0 ?S 07:28 0:00 [kblockd/12] root 682 0.0 0.0 0 0 ?S 07:28 0:00 [kblockd/13] root 683 0.0 0.0 0 0 ?S 07:28 0:00 [kblockd/14] root 684 0.0 0.0 0 0 ?S 07:28 0:00 [kblockd/15] Second, why can't I set a per user limit in limits.conf that is higher than the default (*) limit value? Thanks, Kenny ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
ARTICLE - Red Hat and the Kernel Kerfluffle
A decent writeup about how/why Red Hat changed the way they distribute kernel patches: http://www.linux-mag.com/id/8414/ ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: nproc
My first question is, does anyone know how nproc is calculated? I have seen some issues lately where the limits.conf hard limit is imposed, but the user hasn't exceeded the number of processes. Don't forget that multithreaded processes (Java, WWW browsers, etc) might bump you up against your limits sooner than you expected. The H, L, m or T options (some need dashes?) with ps can show that. [...] Second, why can't I set a per user limit in limits.conf that is higher than the default (*) limit value? I don't know, but I can see why you might wish it worked that way, especially on a system with a lot of users. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Nmap: pissing. me. off.
Hey, all. I'm writing up a script to do auto-provisioning on Asterisk, and it works great thus-far. Went to move it to a different machine, though, and lo! Stopped dead. Digging deeper, I found that nmap -- which I'm calling (in large part because it keeps track of vendor MAC associations) isn't returning MACs. I brought over the executable from machine A (functioning) to machine B... and it exhibits the *exact* same behavior. Syntax: nmap -sP 172.17.7.0/24 Every other machine I try it on returns MACs with a local subnet scan, as root. Except that one. Any ideas? Thanks! -Ken ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Nmap: pissing. me. off.
Went to move it to a different machine, though, and lo! Stopped dead. Digging deeper, I found that nmap -- which I'm calling (in large part because it keeps track of vendor MAC associations) isn't returning MACs. I brought over the executable from machine A (functioning) to machine B... and it exhibits the *exact* same behavior. You're sure the base nmap executable binary bits are the same so it's something specific to the failing machine, yes? Sooo, some preliminary shots in the dark: - Machines same distro? Same architecture? i686 vs. x86_64? - PATH and LD_LIBRARY_PATH are correct? ie. you're actually loading the intended binary and pulling in the intended libs? - execute ldd against the nmap executable on all machines and compare results. ...etc, etc... ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Nmap: pissing. me. off.
On my Ubuntu system it was 755 by default and, as expected, returned MAC address data as root, but not as a non-privileged user. If I chmod ug+s the binary, non-priv users suddenly get MAC data as well. None of this explains why root would ever *not* receive MAC data, however. If it helps an nmap -v shows version 5.00, and I'm using Ubuntu 10.04 Server. On Wed, Mar 16, 2011 at 10:30 PM, Ken D'Ambrosio k...@jots.org wrote: You're sure the base nmap executable binary bits are the same so it's something specific to the failing machine, yes? D'oh! This is what happens when going from window to window while typing replies -- sometimes one xterm looks an awful lot like another. You nailed it: somehow, nmap on the failing machine was -rwxr-xr-x (vs. -rwsr-sr-x on the functioning one). It became obvious I'd missed something when this line popped up in strace: mmap2(NULL, 156036, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE... I *am* curious, now, though: I always thought SUID, etc., bits affected *non*-root users. How is it that root is being denied root privs? ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/ -- Kyle Smith ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/