Hot answers tagged kernel
When the socket is in TIME_WAIT, there is no process attached to it anymore and the kernel is just holding it in case some other packet arrives. At this point, the software the originally opened this socket does not have a open file description to it anymore. That's why you can't find any relation to it. The socket that existed in /proc/$PID/fd is not there ...
First of all, the 2.6 Kernel coming with RHEL 6.5 is far from being an old operating system as it has a BIG amount of backported features from the more recent kernels, comparing to the Vanilla 2.6. When you run RHEL or a direct non modified variant derived from RHEL, you get an enterprise operating system, including the kernel. It is carefully crafted, it ...
I believe you created an orphan socket by killing the connection on the .137 server. So, the kernel parameter in use would be tcp_orphan_retries - which has a generic linux default of 7. You can get a description of both the condition you created and the results here: http://www.linuxinsight.com/proc_sys_net_ipv4_tcp_orphan_retries.html
make -j (with no argument to -j) does not have an upper limit to the number of commands which are started. It parallelizes as much as possible, not just up to the number of cores (as the question sort of suggests). make -j 12 (or maybe less than 12 depending on how memory hungry each process is) is probably a more sane command in your situation. From man 1 ...
A socket in TIME_WAIT status is no longer owned by a process, but by the kernel. As such, there is no owner, that's why you can't see it :)
After digging through the documentation (based on the other answers here), this is the process I ended up using: Start xperf tracing xperf -on base+interrupt Note, you will need to close Process Monitor or any other app which uses ETW or you will get the following error: xperf: error: NT Kernel Logger: Cannot create a file when that file already exists. ...
You can use cgroups in an LXC container, as they are namespaced, but OpenVZ is very old technology and I highly doubt you will find a way to make it work. If you can, you should start converting over from OpenVZ to LXC as the former is likely to be abandoned sooner or later. It's LXC that all those OpenVZ devs have been building.
On SUse 11 Sp2 node01:~ # grep TPROXY /boot/config-3.0.38-0.5-default CONFIG_NETFILTER_TPROXY=m CONFIG_NETFILTER_XT_TARGET_TPROXY=m node01:~ # uname -r 3.0.38-0.5-default I don't knwo the kernel version of ubuntu 14, but anyway, try grep in your kernel config under /boot Filesystem
To get a recent long-term support kernel purpose-built for CentOS 6, consider using kernel-lt from ELrepo.
Only top voted, non community-wiki answers of a minimum length are eligible