突然断电，使得电脑宕机，重新开启docker,发现一致打开不了；

解决Docker启动问题

最新推荐文章于 2025-05-07 09:23:50 发布

原创最新推荐文章于 2025-05-07 09:23:50 发布 · 1.7k 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#docker #运维 #linux

本文介绍了当遇到Docker无法启动的问题时，如何排查并解决。首先检查selinux配置，然后检查系统内存使用情况，通过释放空间来解决问题。

1.先考虑断电对docker有什么影响？查询一番；描述为可能是/etc/selinux/中配置文件config被改了，将 SELINUX=disabled 修改为 SELINUX=permissive 再重启服务器，但是没有解决问题；

2.一直打不开，查询到可能虚拟机linux系统内存已满，导致无法启动docker；

查看了下内存占用命令：df -h ，发现 /dev/mapper/centos-root 已用内存竟然100%；

此时，可以进行删除虚拟机一些没有用的文件；

可输入以下代码，查看具体占用内存情况；

cd / && du -h -x --max-depth=1

如图所示；

在删除某些文件后，腾出空余的空间，重启docker；输入systemctl restart docker

发现成功了

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

洋洋洒洒_晨

关注关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
1
评论
分享

复制链接

分享到 QQ

分享到新浪微博

扫一扫
举报

举报

Linux下微服务系统开机自启（Docker版）——解决异常、常规断电后等待人工运维问题

牟云飞的博客

09-09

898

“Docker下服务开机自启”与“Linux下微服务系统开机自启（非docker开机自启参考地址）”实现方式稍有不同，需要操作系统启动后，自启动docker，然后自启动docker镜像形成容器container，最后docker container执行自启动脚本，自启脚本则是在执行镜像启动时将脚本脚本放入docker run命令中，这样能够实现服务开机自启，实现无人值守下的异常重启，解决异常/常规断电或者操作系统重启后，研发的系统需要等待人工启动服务，否则无法使用的问题，测试效果点击电源键我们的服务就能够启

Docker三剑客之swarm

weixin_46935110的博客

03-14

9280

Swarm是Docker公司推出的用来管理docker集群的平台，几乎全部用GO语言来完成的开发的，代码开源在https://github.com/docker/swarm，它是将一群Docker宿主机变成一个单一的虚拟主机，Swarm使用标准的Docker API接口作为其前端的访问入口，换言之，各种形式的Docker Client(compose,docker-py等)均可以直接与Swarm通信，甚至Docker本身都可以很容易的与Swarm集成，这大大方便了用户将原本基于单节点的系统移植到Swarm

1 条评论您还未登录，请先登录后发表或查看评论

1 条评论

CSDN-Ada助手 2022.11.07
不知道云原生入门技能树是否可以帮到你：https://edu.csdn.net/skill/cloud_native?utm_source=AI_act_cloud_native

CentOs7重启之后，docker服务无法启动

BING_SHA的博客

02-06

1248

怀疑是/usr/lib/systemd/system/docker.service文件有问题，查看此文件并与网上的进行对比，并没有发现问题，把该文件内容粘贴如下。local-kv.db文件记录了docker的网络信息，centos重启可能导致了该文件的损坏，导致网络连接出了问题。从日志中发现docker无法创建网桥，与自定义的网桥br0冲突，并且无法自动连接到自定义的网桥br0（自定义网桥参见。1.首先猜测是有docker进程正在运行中，导致的冲突，查询docker相关进程。服务正常，未启动的状态。

CentOS 7 断电重启后 Docker 无法启动的问题

小康子的博客

04-18

5814

1、问题记录 服务器意外断电重启之后，发现 Docker 服务没有启动，于是手动执行启动命令 systemctl start docker 启动失败，报错如下 Job for docker.service failed because start of the service was attempted too often. See "systemctl status docker.service" and "journalctl -xe" for details. To force a start us

主机异常断电后docker启动失败

我惠依旧的博客

05-07

630

还在为主机异常断电后 Docker 启动失败而烦恼？还在苦苦寻找能让 Docker 重新正常运行的方法而不知所措？现在有一套有效的解决方案可以解决问题。首先，检查 Docker 和 containerd 的配置文件，确保无语法错误和异常配置。接着，查看系统资源，保证内存和磁盘空间充足，若磁盘空间紧张，清理 Docker 容器、镜像、日志及无用文件。再检查 containerd 服务状态，若未运行则启动它。若以上都不行...

服务器断电后docker启动容器失败解决方法，不需删除镜像和修改存储类型

fly0512的博客

07-13

5041

服务器直接断电，重新开机后docker start 容器id报错 /usr/bin/docker-current: Error response from daemon: error creating overlay mount to /var/lib/docker/overlay2/xxxxxxxxxx -init/merged: invalid argument. See '/usr/bin/...

转：记一次Docker断电故障

12-19

736

docker断电启动失败

一旦Docker出现宕机，运行其中的Oracle数据库如何快速恢复？

qqqyyy0422的博客

02-26

801

一旦docker发生宕机，运行在docker中的oracle如何快速恢复？

宕机处理：Kubernetes集群高可用实战总结

会哭的雨@的博客

04-22

3045

导语 |在企业生产环境，Kubernetes高可用是一个必不可少的特性，其中最通用的场景就是如何在Kubernetes集群宕机一个节点的情况下保障服务依旧可用。本文对在该场景下实现集群和应用高可用过程中遇到的各种问题进行了梳理和总结，希望与大家一同交流。文章作者，腾讯云架构服务研发工程师。一、整体架构 1. control plane node 管理节点采用 kubeadm 搭建的 3 节点标准高可用方案：Stacked etcd topology[1]. 该方案中，所有管理节...

CentOS7断电宕机应对宝典：案例分析与预防策略全解析

本文首先概述了CentOS7系统及其在断电宕机中的影响，然后通过案例分析探讨了断电的原因、系统宕机的案例以及宕机后的恢复过程。文章进一步讨论了断电宕机的预防策略，包括硬件防护、系统软件优化、数据备份与恢复...

断电/非正常关机后docker启动失败 Job for docker.service failed because start of the service was attempted too oft

xyouzi的博客

07-25

1901

断电/非正常关机后docker启动失败 Job for docker.service failed because start of the service was attempted too oft

服务器意外断电系统崩溃,Docker 实例不能正常启动可能诱因：服务器意外断电操作系统故障运维操作有误...

weixin_42484858的博客

08-13

1220

标签：[root@bogon ~]# docker psCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES[root@bogon ~]# docker ps -aCONTAINER ID ...

Docker停电事件未解之谜

Dancen的专栏

07-05

2533

周末出现了一次偶然的停电事故，供电恢复后，按照惯例重启服务器，并重新运行各项服务。然而，一台Ubuntu 16.04服务器的Docker容器无法启动了…… 错误信息指出：cgroup的挂载点不存在！从网络查询可知，很多用户都遇到过该错误，一个临时的解决办法是执行以下两条命令：由于这仅仅是一个临时处理办法，系统重启后失效。因此，重启系统后，需要再次执行以上命令，才能正常启动容器，目前暂时没有找到可行的持久化解决方案。参考资料：https://github.com/docker/for-linux/i

docker引擎断电后启动失败常见问题和解决方案

handsomestWei的博客

03-06

1309

docker引擎断电后启动失败常见问题和解决方案

异常断电文件损坏docker服务异常处理

闫玉林的博客

11-07

2030

继续查看更详细的日志，发现启动某个容器时报错了，就去把容器文件夹都删了，还是不行。没招了，重装系统是不可能的，就把docker卸载了，然后重装，可以了。坑爹的是，第一次还原时，忘了把数据库停掉，还原的文件也不对，只好重来。幸好，我每天都对数据库文件夹全量备份，删掉现有的，还原即可。，重启虚拟机，再启动docker解决，我试了下，不行。都解决了，也是实在不想重装虚拟机，就继续搜索解决。数据库关闭，文件夹情况，还原备份文件，搞定。可以了，有输出了，以为好了，很高兴。，还是不行，头大，卡在了启动过程。

【笔记】解决断电后k8s和docker起不来的问题

weixin_48819467的博客

04-28

2702

解决断电后docker和k8s起来不了的问题

Linux关机后Docker无法启动

Java_Glory的博客

12-03

1533

场景：Oracle VM VirtualBox安装的CentOS7虚拟机，直接关机后，Docker无法启动图中可以看到关机后，重新启动Docker无法正常启动，使用ps -ef | grep docker指令查看Docker居然还在，可是无法启动镜像，尝试kill进程后再启动：如果状态还是：Exited。就使用：dockerstart $(CONTAINERID)启动就行了可以看到已经启动成功了，尝试访问一下。网上找了一些资料，发现没有我遇到的这种场景，特此记录一..

记一次windows下docker无法启动的故障

nanj的专栏

07-23

443

由于非法断电，windows上面的docker一直处在Docker is starting无法进入主界面。然后启动docker,经过一会初始化后docker又可以正常启动了。在PowerShell中执行代码。

服务器重启或者机房断电导致程序启动失败

lmy_loveF的博客

11-29

369

服务器重启或者机房断电导致程序启动失败解决方法

cpu 占用一直99% 会不会宕机？

最新发布

09-27

<think>嗯，用户问的是CPU占用一直99%是否会导致宕机。这个问题看似简单，但需要从多个层面来分析。用户提供的引用材料很有价值。引用[1]里提到优化前CPU使用率95%，导致系统性能极差（接口响应2300ms，频繁Full GC），这已经接近宕机状态。引用[2]则提到Redis或MySQL等关键组件崩溃会引发连锁反应。这些实际案例正好佐证CPU持续高负载的危害。用户可能经历过类似故障才会这么问。ta的潜台词或许是：服务器最近总是卡顿，监控显示CPU长期99%，会不会突然挂掉？或者作为运维人员，ta在评估是否要紧急介入处理。从技术焦虑程度看，更像是前者。需要分三个维度回答：首先是直接风险：CPU满载本身不会立刻宕机，但会引发线程阻塞（如引用[1]的2300ms响应）。在Java体系里，这会加剧GC压力——就像案例中Full GC每10分钟发生一次，最终耗尽内存触发OOM。其次是连锁反应：就像引用[2]描述的，当缓存服务因CPU问题失效，流量直接压垮数据库（MySQL宕机案例）。此时整个系统雪崩才是真正的"宕机"。最后是硬件层面：虽然现代CPU有过热保护，但某些云主机散热差（如紧凑型虚拟机），持续100%负载可能触发thermal throttling甚至强制关机——这属于物理宕机。补充个容易被忽略的点：Linux内核的soft lockup检测机制。当CPU被独占超过20秒（默认值），系统可能主动panic重启，这算主动型宕机。应该提醒用户：引用[1]的优化效果很典型（CPU从95%→25%），说明这类问题必须立即处理。可以建议ta用top -Hp找线程，再结合jstack定位具体代码——毕竟74%的下降幅度证明方法有效。用户或许还需要知道：当CPU满载时，连最简单的重启操作都可能因系统无响应而失败（必须物理重启）。这个细节对生产环境很重要。 </think>CPU占用率持续99%**确实可能导致系统瘫痪甚至宕机**，具体风险分层如下： ### 一、直接崩溃风险 1. **线程阻塞雪崩** 当所有CPU核心满载时，新请求线程进入等待队列，响应时间指数级上升（如引用[1]中优化前响应2300ms）。极端情况下，线程堆积会触发操作系统级进程阻塞，导致服务不可用。 2. **资源争夺死锁** 高CPU占用会加剧磁盘I/O、网络等资源的竞争。例如数据库连接池因CPU饥饿无法及时释放连接，最终引发服务连锁崩溃（如引用[2]中MySQL被压垮的场景）。 ### 二、间接宕机路径 || 触发机制 | 典型后果 | |---------|-----------|-----------| | **内存泄漏** | GC线程因CPU饥饿无法执行回收 | JVM OOM崩溃（引用[1]中Full GC频率激增） | | **缓存失效** | Redis等中间件响应超时 | 流量直接穿透击垮数据库（引用[2]场景） | | **硬件过载** | 持续高温触发降频/断电 | 物理服务器强制关机 | ### 三、关键临界点判断 ```mermaid graph LR A[CPU 99%] --> B{持续时长} B -->|＜5分钟| C[系统卡顿但可恢复] B -->|＞15分钟| D[线程阻塞雪崩] B -->|＞1小时| E[内存泄漏/OOM] B -->|伴随高IO| F[磁盘读写死锁] ``` ### 四、生产环境应对建议 1. **紧急处置** ```bash top -c # 定位高负载进程 jstack <pid> > dump.txt # Java线程分析（引用[1]优化手段） perf top # 原生代码性能热点 ``` 2. **防御性设计** - 设置微服务熔断阈值（如CPU>80%自动降级） - 部署负载均衡自动摘除故障节点（引用[2]高可用方案） - 启用容器CPU硬限（`docker run --cpus=0.5`） > 案例佐证：引用[1]中CPU从95%降至25%后，**Full GC频率下降96%**，证明高CPU会通过阻塞GC线程间接导致内存型宕机[^1]。 --- ### 相关问题 1. 如何快速定位导致CPU 99%的Java线程？ 2. 除了CPU限制，Docker容器还有哪些防止资源过载的参数？ 3. 高并发场景下如何避免缓存击穿引发连锁宕机？ 4. 服务器高温告警与CPU负载的关联处理方案有哪些？