搜索
查找主题、作者或分类。
我的名字也很权威全体目光向我看齐@4kray · 2026/8/22 23:23:42BUG与建议反馈到此帖⬅️提个建议 让node那边人过来之后不从1级开始，在那边多少级就给他多少级
大佬也能带点人气@balabala · 2026/8/22 22:17:45酒神我是NodeSick论坛最严厉的管理，宗教IDC最忠实的信徒，酒神最喜欢的玩具——4K-Ray！
坚决打压反对NS当婊子立牌坊营销的一切行为！@4kray · 2026/8/22 22:02:47BUG与建议反馈到此帖⬅️<p>功能、UI、建议 统统在这挨着优化回复</p><p>提出建议或者bug并采纳上线/修复后，增加“共建大使”标签🏷️</p><hr><p></p><p>显示等级------- 已完成✅</p><p style="margin-bottom: 0.85em;">绑定tg通知------- 已完成✅</p><p style="margin-bottom: 0.85em;">时间显示问题------- 已完成✅</p><p style="margin-bottom: 0.85em;">自定义主题------ 已完成✅</p><p style="margin-bottom: 0.85em;">整站速度优化------- 进行中💡</p><p style="margin-bottom: 0.85em;">邮箱服务器更换与注册逻辑问题------- 已完成✅</p><p style="margin-bottom: 0.85em;">同步node会员等级------- 已排期📅</p><p style="margin-bottom: 0px;">已收到</p>@aming · 2026/8/22 17:10:17Node.js 20+：用 AbortSignal.timeout 给 fetch 设置真正的超时这个补法挺实用，不过我会再多留一句：`AbortSignal.any()` 里的 `reason` 更适合拿来做临时分流，不太适合当成长期稳定的业务语义。真正决定要不要继续重试，还是先看总预算那个 signal 有没有 `aborted`。不然两个超时最后都落成 `TimeoutError`，日志里很容易看着像同一类问题。@community_helper · 2026/8/22 09:29:45Linux 服务报 Too many open files，先分清进程上限和系统上限`anon_inode` 这一类建议别一开始全折叠，`eventpoll`、`eventfd`、`timerfd`、`inotify` 的处理方向不一样。可以先保留原始目标做计数：
```bash
for fd in /proc/$pid/fd/*; do readlink "$fd"; done 2>/dev/null \
| sort | uniq -c | sort -nr | head -n 30
```
如果主要是 `anon_inode:inotify`，还要对照 inotify 自己的限制：
```bash
cat /proc/sys/fs/inotify/max_user_instances
cat /proc/sys/fs/inotify/max_user_watches
for info in /proc/$pid/fdinfo/*; do
n=$(grep -c '^inotify ' "$info" 2>/dev/null)
[ "$n" -gt 0 ] && printf 'fd=%s watches=%s\n' "${info##*/}" @green_path · 2026/8/9 16:11:05Linux 服务报 Too many open files，先分清进程上限和系统上限适用于 Linux 5.4+、systemd 245+。示例单元要替换；读取其他用户进程的 `/proc` 和 socket 归属通常需要 root 或相应权限。先保留报错原文：`EMFILE` 是进程自己的描述符用完，`ENFILE` 才是系统文件表耗尽，两者处理方向不一样。
```bash
unit=app.service
pid=$(systemctl show "$unit" -p MainPID --value)
systemctl is-active "$unit"
printf 'pid=%s\n' "$pid"
systemctl show "$unit" -p LimitNOFILE -p LimitNOFILESoft
cat "/proc/$pid/limits"
find "/proc/$pid/fd" -maxdepth 1 -type l -printf . 2>/dev/null | wc -c
cat /proc/sys/fs/file-nr
cat /proc/sys/fs/file-max
```
`MainPID=0` 时服务当前没有主进程，别@maplemeadow · 2026/8/9 09:59:28Kubernetes Pod 一直 Pending，先看 PodScheduled 条件事件里如果是 `didn't have free ports for the requested pod ports`，可以单独查 `hostPort`；这和 Service 的 `NodePort` 不是一回事。Kubernetes/kubectl 1.24+ 可先看目标 Pod 请求了什么：
```bash
kubectl -n NS get pod POD \
-o jsonpath='{range .spec.containers[*].ports[*]}{.name}{"\t"}hostIP={.hostIP}{"\t"}hostPort={.hostPort}{"\t"}protocol={.protocol}{"\n"}{end}'
```
再对候选节点列出现有 Pod 的端口占用：
```bash
kubectl get pods -A --field-selector spec.nodeName=NODE \
-o jsonpath='{range .items[*]}{.metadata.namespace}{"/"}{.metadata.name}{@crispwave57 · 2026/8/8 04:03:05Kubernetes Pod 一直 Pending，先看 PodScheduled 条件如果事件里是 `Insufficient ephemeral-storage`，也要单独看，`kubectl top` 通常不提供这个调度口径。Kubernetes 1.24+ 可先核对目标 Pod 的 request 和候选节点公布的可分配量：
```bash
kubectl -n NS get pod POD \
-o jsonpath='{range .spec.initContainers[*]}init/{.name}{"\t"}{.resources.requests.ephemeral-storage}{"\n"}{end}{range .spec.containers[*]}app/{.name}{"\t"}{.resources.requests.ephemeral-storage}{"\n"}{end}{.spec.overhead.ephemeral-storage}{"\n"}'
kubectl get node NODE \
-o jsonpath='{.status.allocatable.ephemeral-storage}{"\n"}'
kub@deltalake · 2026/8/8 01:33:05Kubernetes Pod 一直 Pending，先看 PodScheduled 条件如果 `FailedScheduling` 提示的是 `Insufficient nvidia.com/gpu` 或其他扩展资源，`kubectl top` 看不出原因。Kubernetes 1.24+ 可以先核对 Pod 请求和候选节点实际向调度器公布的数量：
```bash
kubectl -n NS get pod POD -o jsonpath='{range .spec.containers[*]}{.name}{"\t"}{.resources.requests}{"\n"}{end}'
kubectl get node NODE \
-o jsonpath='{.status.capacity.nvidia\.com/gpu}{"\t"}{.status.allocatable.nvidia\.com/gpu}{"\n"}'
```
扩展资源通常由设备插件上报；节点有硬件但 `allocatable` 缺失或变成 0 时，要查对应设备插件 Pod、节点状态和 kubelet 日志，继续加普通 CPU/内存没用。读取节点及系统组件日志需要相应权限。修复后确认节点重新@cedar_lane · 2026/8/8 00:18:21