CLOSED - 令人费解的系统启动时间长,不知道从哪里开始


10

我知道解决长启动时间涉及分析启动什么所需的时间,但是输出 systemd-analyze blamesystemd-analyze plot 让我困惑不解。

~ $ systemd-analyze
Startup finished in 12.557s (firmware) + 4.516s (loader) + 3.732s (kernel) + 26.720s (userspace) = 47.526s
~ $ systemd-analyze blame | grep "\s[1-9]*\."
          8.989s keyboard-setup.service
          8.757s dev-sda2.device
          6.055s apparmor.service
          4.948s accounts-daemon.service
          4.446s NetworkManager.service
          3.383s gpu-manager.service
          3.134s systemd-udevd.service
          3.079s snapd.firstboot.service
          2.440s udisks2.service
          2.249s grub-common.service
          2.093s upower.service
          1.943s networking.service
          1.661s avahi-daemon.service
          1.461s rsyslog.service
          1.460s pppd-dns.service
          1.449s systemd-tmpfiles-setup-dev.service
          1.387s systemd-rfkill.service
          1.290s colord.service
          1.210s resolvconf.service
          1.192s apport.service
          1.188s systemd-modules-load.service
          1.187s systemd-remount-fs.service
          1.166s dev-mqueue.mount
          1.152s bluetooth.service
          1.032s lightdm.service
          1.013s plymouth-quit-wait.service

Output of systemd-analyze plot

信息

这台机器是戴尔Inspiron 5559;我从2016年2月/ 3月开始就拥有它。

~ $ uname -imporvs
Linux 4.8.0-32-generic #34-Ubuntu SMP Tue Dec 13 14:30:43 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Distro是Lubuntu 16.10 w / LXDE。

~ $ sudo parted /dev/sda unit mib print
Model: ATA ST1000LM024 HN-M (scsi)
Disk /dev/sda: 953870MiB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: 

Number  Start      End        Size       File system     Name                  Flags
 1      1.00MiB    513MiB     512MiB     fat32           EFI System Partition  boot, esp
 2      513MiB     937591MiB  937078MiB  ext4
 3      937591MiB  953869MiB  16278MiB   linux-swap(v1)

最糟糕的是,各个模块的时间有所不同(1到2秒,从我安装Lubuntu后出现此问题),这意味着我需要更新 systemd-analyze blame 不断或记录一系列重新启动,然后进行平均。

任何人都可以告诉我在哪里 开始

UPDATE

通过16.10升至17.04升级 sudo apt dist-upgrade 大大改变了这种情况。
~ $ systemd-analyze blame | grep "\s[1-9]*\."
         16.083s dev-sda2.device
         15.435s keyboard-setup.service
          8.015s systemd-udevd.service
          4.090s NetworkManager.service
          3.644s systemd-tmpfiles-setup-dev.service
          2.621s apparmor.service
          2.549s grub-common.service
          2.477s plymouth-read-write.service
          1.560s accounts-daemon.service
          1.107s systemd-modules-load.service
          1.002s colord.service
~ $ systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @25.631s
└─multi-user.target @25.631s
  └─getty.target @25.631s
    └─getty@tty1.service @25.631s
      └─system-getty.slice @25.630s
        └─setvtrgb.service @25.407s +222ms
          └─systemd-user-sessions.service @25.245s +2ms
            └─network.target @25.245s
              └─NetworkManager.service @21.154s +4.090s
                └─dbus.service @21.147s
                  └─basic.target @21.139s
                    └─sockets.target @21.139s
                      └─snapd.socket @21.136s +2ms
                        └─sysinit.target @21.110s
                          └─apparmor.service @18.488s +2.621s
                            └─local-fs.target @18.488s
                              └─boot-efi.mount @18.387s +100ms
                                └─systemd-fsck@dev-disk-by\x2duuid-7930\x2d6EDD.service @18.198s +150ms
                                  └─dev-disk-by\x2duuid-7930\x2d6EDD.device @18.198s

Output of systemd-analyze plot 至少有明显的罪魁祸首出现。

关闭

这个帖子正在关闭,因为我已经迁移到另一个没有出现问题的发行版(Gentoo),所以这个问题已经不再适用了。


好吧,我有一个领导是提到的一些服务 systemd-analyze blame (特别是 keyboard-setup.service )是位于/etc/init.d中的SysVInit样式脚本。虽然我不知道如何替换基于脚本的服务......
setun-90

grep "\s[1-9]\." 你有什么理由过滤掉加载时间> 10秒的服务?放一个 + 之后 ] 匹配一个或多个数字。
Jacob Krall

@JacobKrall我没有完全过滤它们,只是我没有任何服务与> 10s加载时间,因此是一位数。我匆匆做了这件事......并且“+”对我不起作用,'*'做了。
setun-90

好的,抱歉打扰了。这很奇怪 + 没用;它是GNU Grep中的重复运算符之一 gnu.org/software/grep/manual/grep.html#Fundamental-Structure
Jacob Krall

@JacobKrall我也觉得这也很奇怪。稍后调试。
setun-90

Answers:


1

谁能告诉我在哪里可以开始?

运行实时Ubuntu会话(或“尝试不安装”功能附带的任何发行版)

很多时候,基于Linux的发行版需要很长时间才能启动,甚至在键盘或NIC等外围组件出现问题时无法启动。例如,我的旧笔记本电脑键盘的“向上”按键仍保持按下状态而不会被物理按下。因此,keyboard-setup.sh等待很长时间,无法完成,最后我看到一堆错误消息,通知我Ubuntu无法启动。在启动过程中断开键盘是让我启动它的解决方法。

测试你的 硬件 对于这种类型的错误将是一个很好的起点。如果您了解笔记本电脑的硬件问题,可以尝试在启动期间断开该组件(可能是NIC或键盘,因为您提到了polktid和keyboard-setup.sh)


谢谢你提到硬件,我没有想到这一点。虽然我也应该在问题中提到我将发行版升级到17.04并且启动时间略有改变(现在udevd是主要罪魁祸首),但我认为keyboard-setup.sh仍然需要很长时间。我会更新。
setun-90

请在你的问题中提到这一点。您升级了哪个版本?从LTS升级到版本总是会导致问题。如果您从16.xx LTS升级到17.04,则必须进行17.04的全新安装。我坚持尝试17.04的现场会议。如果实时会话正常启动,那么干净安装肯定会解决问题。
sziraqui

对不起,在此问题被提出后,我同时进行了升级。启动时间实际上缩短了一两秒。但是,是的,我想一个干净的重新安装可以做点什么。顺便说一下,我认为16.10不是LTS。
setun-90

还有一点需要注意,你不能 正式 从LTS(例如16.xx,14.xx)更新到版本(例如15.xx,17.xx),反之亦然。您可以使用isocourse进行更新,但它总是会导致系统错误。我猜你已经从iso升级了,这就是为什么我建议做一个干净的安装。如果是这种情况,我会更新我的答案,这可能在将来帮助其他人。
sziraqui

我没有使用ISO,升级的提议有一天通过Synaptic出现,然后我跑了 sudo apt dist-upgrade
setun-90
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.