2023年10月

一个进程结束后，会返回一个返回值，父进程会用wait()来获取这个返回值，等获取到之后，系统会回收进程的pcd并删除对应的进程，但如果父进程一直不获取，那么这个进程会处于僵尸状态

处理思路：

僵尸进程是已经结束的进程，无法用kill杀死，首先得去看看他的父进程出了什么事情，为什么不获取

ps -p pid -o stat | tail -n 1

如果父进程停止了（T），那么恢复父进程就行
kill -SIGCONT pid

如果父进程正常，用strace -p pid去追踪他的行为，看看是不是发生了死锁之类的

如果是孤儿进程（父进程先一步退出了），那么这种进程一般会被初始进程接管，这种情况下要是还是出了问题，那看看是不是初始进程出事了，方法参上

注：高版本的初始进程不再会被kill发送的停止信号影响，也不能被strace

https://blog.csdn.net/lovely_nn/article/details/123043447

- job_name: kubelet/metrics
  honor_labels: true
  honor_timestamps: true
  scrape_interval: 15s
  scrape_timeout: 10s
  metrics_path: /metrics
  scheme: https
  kubernetes_sd_configs:
  - role: node
  bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
  tls_config:
    ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
    insecure_skip_verify: false
  relabel_configs:
  - separator: ;
    regex: __meta_kubernetes_node_label_(.+)
    replacement: $1
    action: labelmap
  - separator: ;
    regex: (.*)
    target_label: __address__
    replacement: kubernetes.default.svc:443
    action: replace
  - source_labels: [__meta_kubernetes_node_name]
    separator: ;
    regex: (.+)
    target_label: __metrics_path__
    replacement: /api/v1/nodes/${1}/proxy/metrics
    action: replace
  - separator: ;
    regex: (.*)
    target_label: job
    replacement: kubelet
    action: replace

某个磁盘满了，但是进去找不到文件，排除掉权限、隐藏文件、硬件问题等之后，那还有种可能

lsof -n |grep deleted

kill 杀掉对应进程

出现问题的原因是文件虽然被删除，但是进程没有释放文件的句柄，导致内核不能正常释放对应的存储空间

监控报容器的内存报警，但是进容器查看发现实际没有使用那么多的内存，再看监控数据，确实是超了预警值触发了告警
看配置的指标，用的是container_memory_working_set_bytes和kube_pod_container_resource_limits_memory_bytes ，kube_pod_container_resource_limits_memory_bytes 是当前容器内存限制大小，container_memory_working_set_bytes通过查看cadvisor可知是memory.usage-total_inactive_file，也就是cgroup的memory.usage_in_bytes

进容器的/sys/fs/cgroup/memory目录下

memory.usage_in_bytes 已使用的内存量(包含cache和buffer)(字节)，相当于linux的used_meme
memory.limit_in_bytes 限制的内存总量(字节)，相当于linux的total_mem
memory.failcnt 申请内存失败次数计数
memory.stat 内存相关状态

memory.usage_in_bytes的计算方式包含rss+cache+buffer，total_active_file和total_inactive_file都包含在cache，cache是不会主动回收的，只有当容器被销毁或者系统内存不足才回去回收，所以才会出现上面的情况

参考博客：https://blog.csdn.net/weixin_39961559/article/details/80496419
https://blog.csdn.net/weixin_39961559/article/details/86432283
https://www.cnblogs.com/276815076/p/5478966.html

登一台以前登过的服务器，但是ssh报了个错

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:xxxx
Please contact your system administrator.
Add correct host key in /Users/td/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /Users/td/.ssh/known_hosts:64
Host key for xxx has changed and you have requested strict checking.
Host key verification failed.

一开始还以为哪个给我key整掉了，问了下原来是重装了，把/Users/td/.ssh/known_hosts里面原来的登录记录删掉就行了

  1. 1
  2. 2
  3. 3
  4. 4