在我们的 linux rhel 服务器上fs.file-max设置100000
sysctl -p | grep fs.file-max
fs.file-max = 100000
据我了解，file-max 内核参数指的是打开的文件描述符，而 file-nr 为我们提供了当前打开的文件描述符的数量。但是 lsof 会列出所有打开的文件，包括不使用文件描述符的文件——例如当前工作目录、内存映射库文件和可执行文本文件。
所以回到我的问题
剂量以下 lsof ，真的很好地表明我们达到了 fs.file-max 值吗？
lsof | wc -l
或者
[[ ` lsof | wc -l ` -gt 100000 ]] && echo "please increase the fs.file-max"
在 Ubuntu/Debian 下的 lsof 命令中，我看到很多行如下：
PROGRAM 829 root 140u sock 0,8 0t0 244182 protocol: TCP
这些线是什么？
它们可能是 TCP 连接尝试失败的结果吗？
以下命令生成了由 PID 30661 打开的 unix 域套接字
$ sudo lsof -U -a -p 30661
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
haproxy 30661 haproxy 7u unix 0xc784a000 0t0 3348210055 /var/lib/haproxy/stats.30660.tmp
我想要一个使用 lsof 内部选项的命令将输出作为“var/lib/haproxy/stats.30660.tmp”
我不想使用管道和其他工具来获取此输出。
我在一个盒子上有很多进程在监听多个端口。
我正在尝试将端口映射到 pid。
问题是 lsof 没有告诉我哪些端口属于哪个进程。
给定一个监听端口 80 的 apache，我可以看到它通过 netstat 监听：
user@host% netstat -an|grep LISTEN|grep 80
*.80 *.* 0 0 49152 0 LISTEN
但是当我尝试将端口 80 映射到 pid 时，我什么也得不到：
user@host% lsof -iTCP:80 -t
当我尝试查看特定 pid 正在使用的套接字时，我得到：
user@host% lsof -lnP -p31 -a -i
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
libhttpd. 31 0 15u IPv4 0x6002d970b80 0t0 TCP *:65535 (LISTEN)
请注意 NAME 列中的 *:65535。
有谁知道为什么 lsof 没有报告正在使用的端口？
我以root身份运行。我正在使用 lsof 和 os 版本的混合：
Solaris10 上的 lsof v4.77 sparc
lsof v4.72 上 Redhat4.2
等
我知道 linux 解决方案可以使用“netstat -p”，
所以我想我只是在寻找 solaris 不工作的原因，但我发现 lsof 经常保持沉默并且没有向我显示预期的数据。
进程 ID 为 2147 的进程正在运行，但找不到其日志文件。文件系统是 ext3，还有 100MB 的空间。进程 2147 没有任何问题。进程 2147 的 lsof 显示日志文件仍处于打开状态。
一个。发生了什么导致日志文件消失？
湾。你能访问文件的内容吗？如果是这样，怎么做？
我想更改 example.com 的工作 apache 配置（exampleIP = 1.2.3.4）以从默认端口 80 更改为端口 8001，这样http://example.com:8001应该可以工作。我无法这样做，并将记录我的尝试。我想我可能需要有关 iptables 的帮助。
我的 /etc/hosts 首先很好
1.2.3.4 example.com
我开始在以下地方用 8001 替换端口 80
/etc/apache2/ports.conf
听 1.2.3.4:8001
/etc/apache2/conf.d/virtual.conf
名称VirtualHost 1.2.3.4:8001
/etc/apache2/sites-enabled/example.com
<虚拟主机 1.2.3.4:8001>
ServerName example.com:8001
#UPDATE: ServerName example.com doesn't make a difference either
</虚拟主机>
当我用 80 替换上述 3 种情况中的 8001 时，它可以工作。使用 8001 我无法建立连接。tcpdump 也不会显示传入的请求。
由于重新启动时的 apache 守护进程没有抛出任何错误，我尝试确认网络服务器是否正在侦听 8001
$ sudo lsof -i |grep 8001
apache2 731 root 3u IPv4 46858730 TCP example.com:8001 (LISTEN)
apache2 734 www-data 3u IPv4 46858730 TCP example.com:8001 (LISTEN)
apache2 736 www-data 3u IPv4 46858730 TCP example.com:8001 (LISTEN)
apache2 737 www-data 3u IPv4 46858730 TCP example.com:8001 (LISTEN)
apache2 738 www-data 3u IPv4 46858730 TCP example.com:8001 (LISTEN)
apache2 739 www-data 3u IPv4 46858730 TCP example.com:8001 (LISTEN)
它似乎在 8001 上监听。我什至尝试将以下 iptable 规则应用于终端：
$ sudo iptables -A INPUT -p tcp --dport 8001 -j ACCEPT
$ sudo iptables -A OUTPUT -p tcp --sport 8001 -j ACCEPT
$ sudo iptables -A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7
我从来没有收到拒绝日志。这是 iptables 详细模式显示的内容
$ sudo iptables -L -v -n
Chain INPUT (policy ACCEPT 3052M packets, 785G bytes)
pkts bytes target prot opt in out source destination
25 1690 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8001
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8001
92 6484 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 5/min burst 5 LOG flags 0 level 7 prefix `iptables denied: '
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 4317M packets, 695G bytes)
pkts bytes target prot opt in out source destination
20 1760 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:8001
我不熟悉 iptable 规则，所以我在上面错过的任何规则的提示都会很棒。阅读其他线程我也想知道这是否是一个原因。
$ cat /proc/sys/net/ipv4/conf/eth0/forwarding
0
鉴于此信息，有什么提示可以阻止在 8001 而不是在 80 上运行的网络服务器？
更新 1： 我尝试刷新所有 iptable 规则
$ sudo iptables -X
$ sudo iptables -F
我也试着看看 tcpdump 是否捕捉到任何东西
sudo tcpdump -i eth0 port 8001 -v
它不在 8001 上，但将端口更改为 80（再次在 ^ 3 个位置），它确实如此。
我试图寻找建立和倾听的过程
$ netstat -an
tcp 0 1.2.3.4:8001 0.0.0.0:* LISTEN
最后从我的本地机器上，我也尝试了 curl
curl http://1.2.3.4:8001 -v
* About to connect() to 1.2.3.4 port 8001 (#0)
* Trying 1.2.3.4... No route to host
* couldn't connect to host
* Closing connection #0
curl: (7) couldn't connect to host
更新 2
此外，我捕获 iptables 错误的 /etc/log/messages 似乎抛出了以下内容。但事实证明，这些出现在您进入和退出 tcpdump 时。
Jan 22 09:30:31 node1 kernel: device eth0 entered promiscuous mode
Jan 22 09:30:31 node1 kernel: audit(1264152631.798:54): dev=eth0 prom=256 old_prom=0 auid=4294967295
Jan 22 09:30:33 node1 kernel: device eth0 left promiscuous mode
更新 3 在 tcpdump 常见问题解答中找到了这个
...这可能是因为您正在捕获的接口已插入开关；在交换网络上，两个端口之间的单播流量不一定会出现在其他端口上 - 只有广播和多播流量才会发送到所有端口......
...这表明如果您在 10Mb 端口上嗅探，您将看不到 发送到 100Mb 端口的流量，反之亦然...
...如果您的机器未插入交换网络或双速集线器，或者它已插入交换网络但端口设置为将所有流量复制到它，问题可能是网络接口您正在捕获 的不支持“混杂”模式，或者因为您的操作系统无法将接口置于混杂模式......
所以总结一下这个特殊的案例：
我正在监视服务器上的 TCP 堆栈，希望一般推断出盒子上的应用程序问题。
我的第一个倾向是测量所有报告状态（LISTEN、ESTABLISHED、FIN_WAIT2、TIME_WAIT 等）的套接字数量并检测一些异常情况。
一位队友建议“lsof”是查看 TCP 堆栈处于什么状态的更好工具。
来自服务器故障人群的任何偏好或经验提示？
