服务启动失败排查思路(work3)

1.看服务日志有无报错
2.若日志未提示,切换至启动服务用户,linux执行脚本,看脚本日志返回是否报错具体
3.若脚本日志报错信息无法排查,考虑排查是否设备内存已满导致启动服务失败(df -h 看服务所在磁盘内存余量)
4.若设备磁盘内存余量有空间,free -h(看虚拟内存占用情况)
5.若虚拟内存也有余量,排查服务端口是否被占用(lsof -i :端口号)
6.可结合日志查看服务端口号,尝试kill -9 端口号,再次启动服务,查看启动情况
7.ps -ef|grep 服务名,看返回结果中服务进程号及时间,看服务启动情况
8.若服务实际启动,脚本返回为未启动,则可能是脚本编写逻辑有异常,更新脚本即可

  • 2
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
排查pod启动失败的问题,可以使用以下命令进行排查: 1. 使用命令 `kubectl get pods` 查看pod的状态,如果状态为 CrashLoopBackOff,说明pod启动失败。 2. 使用命令 `kubectl describe pods <pod-name> -n <namespace>` 查看pod的详细信息,包括错误信息。例如,如果错误信息显示为 "read-only file system error",则可能是由于文件系统只读导致的问题。 3. 检查容器的启动时间是否过长,可以通过调整容器的 `initialDelaySeconds` 参数来延迟探测容器的启动。如果容器还没完全启动就开始探测,可能会导致检查失败,然后pod会被kill并不断重启。另外,节点负载过高也可能导致pod启动失败,可以查看节点的负载情况。 4. 检查kubelet是否报错,可以使用命令 `kubectl describe pods <pod-name> -n <namespace>` 查看pod的事件,进而判断是否有kubelet报错。例如,若报错信息为 "OCI runtime create failed: container_linux.go:348: starting container process caused "process_linux.go:301: running exec setns process for init caused \"signal: killed\"": unknown",则可能是拉取镜像失败导致的问题。 5. 如果pod的状态为 Pending,说明pod还没有调度到某个节点上。可以使用命令 `kubectl describe pods <pod-name> -n <namespace>` 查看pod的事件,进而判断为什么没有调度。例如,Events中可能会显示 "FailedScheduling",并给出具体的原因,如 "0/4 nodes are available: 2 Insufficient cpu",表示节点资源不足。 通过以上命令和步骤,可以帮助你排查pod启动失败的问题,并找到解决方案。<span class="em">1</span><span class="em">2</span><span class="em">3</span><span class="em">4</span>
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值