标签: kernel

我正在运行一个没有交换的 Linux 工作站，并且我已经安装了earlyoom守护进程，以便在 RAM 不足时自动终止一些进程。它earlyoom通过监视内核MemAvailable值来工作，如果可用内存变得足够低，它会杀死不太重要的进程。

这已经工作了很长一段时间，但突然间我遇到了MemAvailable与系统其他部分相比突然非常低的情况。例如：

$ grep -E '^(MemTotal|MemFree|MemAvailable|Buffers|Cached):' /proc/meminfo 
MemTotal:       32362500 kB
MemFree:         5983300 kB
MemAvailable:    2141000 kB
Buffers:          665208 kB
Cached:          4228632 kB

请注意 MemAvailable 远低于MemFree+ Buffers+ Cached。

我可以运行任何工具来进一步调查为什么会发生这种情况吗？我觉得系统性能比正常情况要差一些，我不得不停止该服务，因为除非稳定（即它正确地描述了用户模式进程的可用内存），earlyoom否则它的逻辑将无法工作。MemAvailable

根据https://superuser.com/a/980821/100154 MemAvailable 是对可用于启动新应用程序（无需交换）的内存量的估计。由于我没有交换，这是什么意思？这是否意味着在触发 OOM Killer 之前新进程可以获取的内存量（因为这在逻辑上会遇到“交换已满”的情况）？

我曾假设MemAvailable>=MemFree总是正确的。不在这里。

附加信息：

在互联网上搜索表明，原因可能是打开的文件不受文件系统支持，因此无法从内存中释放。该命令sudo lsof | wc -l输出653100所以我绝对无法手动浏览该列表。

顶部sudo slabtop说

 Active / Total Objects (% used) …

我正在尝试以编程方式踩踏 RHEL5 上的蓝牙。

我已经停止了服务——没问题。rpm -e相关的蓝牙包 bluez-*也没有问题。

ps -aef | grep -v grep | egrep -c '(sdpd|hcid)'

返回零，所以我知道守护进程已经消失了。

出于某种原因，我无法卸载模块。 modprobe -rv一直说它们在使用中。

依赖项如下所示：

bluetooth -> bnep
          -> l2cap 
                 -> rfcomm
                 -> hidp
          -> rfcomm
          -> hidp

但是，即使从顶部开始以便依赖项很简单，也会modprobe -rv bluetooth返回FATAL: Module bluetooth is in use。

那么，我如何找出正在使用这个模块的进程？它似乎不在 /proc/modules 或 lsof 中。

命令lsof仍然显示出一些钩子。

# lsmod | egrep '(bnep|hidp|rfcomm|l2cap|bluetooth)'
bnep                   82241  0 
hidp                   83521  0 
rfcomm                104809  0 
l2cap                  89281  5 bnep,hidp,rfcomm
bluetooth             118597  4 bnep,hidp,rfcomm,l2cap

在一台 linux 服务器（Gentoo 强化）上，我们不时在 dmesg 中遇到以下消息的爆发：

TCP: Treason uncloaked! Peer xx.xx.xxx.xxx:65039/80 shrinks window 4094157295:4094160199. Repaired.

有什么我们应该注意的吗，或者这是正常的吗？

更新：也许相关，我们正在使用net.ipv4.tcp_congestion_control = cubic. 内核版本为 2.6.28，带有 Gentoo 强化补丁。

更新：这可能真的与硬件/驱动程序问题有关，因为我们有时会在交换机上看到“hickup”：端口关闭并再次出现。直到最近我们才发现以下与这些端口故障相关的 dmesg 输出：

[5781269.910133] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
[5781269.910136]   Tx Queue             <0>
[5781269.910137]   TDH                  <e0>
[5781269.910139]   TDT                  <76>
[5781269.910140]   next_to_use          <76>
[5781269.910141]   next_to_clean        <da>
[5781269.910143] buffer_info[next_to_clean]
[5781269.910144]   time_stamp           <22750e54>
[5781269.910146]   next_to_watch        <e2>
[5781269.910147]   jiffies              <22750f5f>
[5781269.910148]   next_to_watch.status <0>

通常在这些记录的行之后还有一些“Treason uncloaked”行（但反之亦然，这意味着这些行并不总是在“Treason uncloaked”之前记录）。

当 Linux 内核检测到 SYN Flooding 时，它会记录如下消息：

possible SYN flooding on port 80. Sending cookies

有谁知道内核用来检测这个的确切方法？

我正在尝试为 Linux 内核 arp 缓存超时配置合理的值，但我找不到有关它们如何在任何地方工作的详细说明。即使 kernel.org 文档也没有给出很好的解释，我只能找到推荐值来缓解溢出。

这是我拥有的价值观的一个例子：

net.ipv4.neigh.default.gc_thresh1 = 128
net.ipv4.neigh.default.gc_thresh2 = 512
net.ipv4.neigh.default.gc_thresh3 = 1024

现在，从我迄今为止收集到的：

• gc_thresh1 是垃圾收集器开始删除任何条目之前允许的 arp 条目数。

• gc_thresh2 是软限制，它是垃圾收集器主动删除 arp 条目之前允许的条目数。

• gc_thresh3 是硬限制，高于此数字的条目将被积极删除。

现在，如果我理解正确的话，如果 arp 条目的数量超过 gc_thresh1 但仍低于 gc_thresh2，则超出部分将定期删除，间隔由 gc_interval 设置。

我的问题是，如果条目数超过 gc_thresh2 但低于 gc_thresh3，或者如果数量超过 gc_thresh3，如何删除条目？换句话说，“积极地”和“积极地”删除到底是什么意思？我认为这意味着它们比 gc_interval 中定义的更频繁地被删除，但我找不到多少。

我将我的 RHEL 5&6 服务器设置为在更新后保留 1 个旧内核，我这样做是为了以防我因各种原因需要恢复系统。我的问题与使用最新内核运行时系统的安全性有关，但仍然安装了旧内核的副本。当我用 Retina 扫描它们时，我总是得到旧内核的命中，但系统正在以最新版本运行。我猜 Retina 只是检查系统上内核的存在，而不是确定它是否是当前正在运行的内核。我的问题是系统上仅存在旧内核是否构成安全问题？有什么想法吗？

如果您从阵列中移除组件 HDD，它会掉入“(initramfs)”下的“busy box”外壳，并在 RAID1 阵列变为“非活动状态”时显示类似于“无法安装根设备”的内容。

可以使用以下方法启动它：

(initramfs): mdadm --run /dev/md0
(initramfs): exit

之后，它使用启动的 RAID1 正常启动（文件系统在 RAID1 阵列上），并且将继续正常启动，直到您移除另一个驱动器（在这种情况下它会完全相同）。

Google 使用“ BOOT_DEGRADED=true ”吐出了一堆关于 UBUNTU 的帖子，但这对 DEBIAN 不起作用。

还有一篇关于使用“ md-mod.start_dirty_degraded=1 ”作为内核映像的引导参数的帖子。我试过在 GRUB 菜单选项中传递它，但无济于事。

可能有一些东西可以解释它，但我是一个新手来理解:(

有任何想法吗？

我知道如果一个进程进入D状态则意味着它处于不可中断状态。该进程不能被任何信号杀死。它只会在重新启动或 I/O 等待结束时退出该状态。

我有很多进程处于D状态，这表明我的机器有问题。即使重新启动后，它们也会回到D状态。我在网上搜索并发现wchanps 输出中的部分告诉我的进程正在等待内核中的什么内容。

当我使用这个命令时，ps axl| grep D我进入-了 wchan 专栏，并且网上没有解释这是什么意思。

这是我的上述命令的示例输出。

0     0  69970      1  20   0  25064  1088 -      D    ?          0:00 ls -l

我无法理解-上面输出的含义。

我管理一些运行 Amazon Linux（不确定是什么版本）的 EC2 实例，这些实例需要安全补丁。

很多软件都打了很好的补丁，但我们一直停留在内核升级上。我们无法按照我们的意愿使用最新的内核版本。我们做了什么？

1. 通过执行从 Amazon 存储库获取最新的内核版本yum update。系统报告我们已经获得了预期的最新内核版本，并且不再需要更新任何内容。
2. 获得最新的内核版本后，我们通过单击 EC2 控制台上的“重新启动”来重新启动 EC2。EC2重启后，我们使用命令检查了EC2的内核版本uname -r。它报告我们仍然使用相同的内核版本，而不是我们期望的最新内核版本。

我们错过了什么要点？请帮忙。

更新 Arch Linux (sudo pacman -Syu) 并重启系统后，由于 kube-proxy 导致 Minikube 无法启动。日志显示它正在尝试修改，/proc/sys/net/netfilter/nf_conntrack_max但遇到了权限被拒绝的问题。

我试图运行，sudo chmod 777 /proc/sys/net/netfilter/nf_conntrack_max但系统不允许我。我也删除~/.minikube并重新开始，但它仍然拒绝工作。启动时同样的问题kind。谁能告诉我如何解决这个问题？

$ kubectl get pods -n kube-system

NAME                               READY   STATUS    RESTARTS   AGE
coredns-74ff55c5b-2hkpd             0/1     Running   0          22s
etcd-minikube                      0/1     Running   0          30s
kube-apiserver-minikube            1/1     Running   0          30s
kube-controller-manager-minikube   0/1     Running   0          30s
kube-proxy-qhhx9                   0/1     Error     2          22s
kube-scheduler-minikube            0/1     Running   0          30s
storage-provisioner                1/1     Running   0          35s

kubectl logs kube-proxy-qhhx9 -n kube-system

I0511 04:47:08.189373       1 node.go:172] Successfully retrieved …