小智 46
您可以尝试找出 systemd 花费最多时间的内容
systemd-analyze blame
小智 29
编辑 /etc/fstab 的交换空间的UUID（以匹配 的输出sudo blkid）就像一个魅力！
注意：之后，如果/etc/crypttab文件中有任何交换条目，您应该通过 UUID 或路径（即 UUID=something 或 /path/to/swap）更改其第二个参数以匹配您的交换空间。
在我的 SSD 上，启动时间从 2 分钟缩短到不到 10 秒。
问题是，当这个问题开始时，我只是从 14.04 到 16.04 进行了正常升级，没有搞乱分区。显然，升级过程存在一些问题。
小智 12
升级后我遇到了类似的启动时间较长的问题。
出了什么问题？ 我删除了我的交换空间，所以我的 /etc/fstab 文件和新文件系统有冲突。Boot loader 等了将近 1m 30s 才找到它。
我是如何解决问题的 运行 sudo blkid
打开您的 /etc/fstab 文件并将 uuid 的匹配与您拥有的分区进行比较。如果不匹配，请更改并重新启动。
Mir*_*rek 10
这是一个变通解决方案，但这显着减少了我的启动时间（从 1 分 24 秒到 16 秒）。
sudo vim /etc/systemd/system.conf
取消对这两个参数的注释并设置所需的超时时间：
DefaultTimeoutStartSec=10s
DefaultTimeoutStopSec=10s
注意：请优化这些值以满足您的硬件需求 ~ 5 - 60 秒。
如所讨论的在这里这些参数配置用于开始和单位停止，以及默认时间为单位的自动重新启动之间睡眠默认超时，作为配置的单位中TimeoutStartSec=，TimeoutStopSec=和RestartSec=（对于服务，请参见systemd.service（5），用于有关每单位设置的详细信息）。
对于非服务单位，DefaultTimeoutStartSec=设置默认值TimeoutSec= value。DefaultTimeoutStartSec=并DefaultTimeoutStopSec=默认为 90 秒。DefaultRestartSec=默认为 100 毫秒。
编辑 - 更详细：
我分析了启动顺序systemd-analyze plot > sequence.svg，显示服务无法在我新升级的操作系统上启动。有三个 - 一个是配置错误的sendmail守护进程，然后是powerd.service和NetworkManager-wait-online.service。由于完全禁用 NetworkManager 服务不是一个好主意，我只是让它在 10 秒后超时并全局应用此规则。
这可能与文件系统问题有关。您可能需要检查此链接以查看修复文件系统是否可以缩短启动时间： https: //help.ubuntu.com/community/FilesystemTroubleshooting
| 归档时间： |
|
| 查看次数： |
108843 次 |
| 最近记录： |