我已经使用 Fedora 24 大约两周了，令我困扰的一件事是真的启动时间较长。我一直试图通过调查这个问题systemd-analyze，systemd-analyze blame似乎有一些启动服务需要相当长的时间，大部分是plymouth-quit-wait.service.由于我对 Linux 还很陌生，所以我无法确定该服务是否是真正的原因，或者是否只是需要等待其他事情发生。我不知道这是否相关，但我在配备 i5-2540M CPU 的 Lenovo Thinkpad X220 上使用 Fedora 24 的工作站版本。我将把systemd-analyze,systemd-analyze blame和的输出附加systemd-analyze critical chain到这个问题上。
systemd-analyze
Startup finished in 2.546s (kernel) + 4.697s (initrd) + 1min 33.630s (userspace) = 1min 40.874s
systemd-analyze blame
49.647s plymouth-quit-wait.service
28.356s dnf-makecache.service
13.163s systemd-journal-flush.service
12.147s firewalld.service
11.119s systemd-udev-settle.service
9.478s dev-mapper-fedora\x2droot.device
7.549s libvirtd.service
5.923s udisks2.service
5.694s abrtd.service
5.658s accounts-daemon.service
5.312s chronyd.service
4.585s polkit.service
3.809s lvm2-pvscan@8:2.service
3.594s unbound-anchor.service
2.736s ModemManager.service
2.430s proc-fs-nfsd.mount
2.367s lvm2-monitor.service
2.287s cups.service
2.283s dmraid-activation.service
2.121s systemd-rfkill.service
2.053s plymouth-start.service
2.033s systemd-logind.service
2.014s gssproxy.service
1.873s systemd-tmpfiles-setup-dev.service
1.830s packagekit.service
1.803s rtkit-daemon.service
1.794s NetworkManager.service
1.792s avahi-daemon.service
1.700s systemd-udevd.service
1.678s bluetooth.service
1.423s fedora-readonly.service
1.367s systemd-backlight@backlight:intel_backlight.service
1.161s abrt-ccpp.service
1.095s wpa_supplicant.service
972ms gdm.service
798ms systemd-journald.service
795ms dev-mqueue.mount
790ms upower.service
738ms systemd-random-seed.service
734ms [email protected]
695ms systemd-fsck@dev-disk-by\x2duuid-bc0eb656\x2d624f\x2d4c3d\x2d90a3\x2d321abc24867b.service
694ms systemd-fsck@dev-mapper-fedora\x2dhome.service
684ms auditd.service
656ms tmp.mount
621ms sys-kernel-debug.mount
521ms systemd-sysctl.service
479ms fedora-import-state.service
438ms rpc-statd-notify.service
395ms systemd-tmpfiles-setup.service
364ms iio-sensor-proxy.service
356ms dev-hugepages.mount
319ms home.mount
299ms systemd-fsck-root.service
280ms dracut-shutdown.service
254ms systemd-user-sessions.service
232ms boot.mount
230ms plymouth-read-write.service
226ms systemd-remount-fs.service
222ms colord.service
163ms systemd-udev-trigger.service
149ms kmod-static-nodes.service
136ms systemd-tmpfiles-clean.service
132ms nfs-config.service
89ms [email protected]
87ms blk-availability.service
76ms dev-mapper-fedora\x2dswap.swap
73ms systemd-vconsole-setup.service
70ms systemd-update-utmp.service
28ms livesys.service
15ms livesys-late.service
9ms var-lib-nfs-rpc_pipefs.mount
6ms systemd-update-utmp-runlevel.service
5ms sys-fs-fuse-connections.mount
2ms sys-kernel-config.mount
systemd-analyze critical chain
graphical.target @1min 33.616s
└─multi-user.target @1min 33.616s
└─libvirtd.service @37.051s +7.549s
└─remote-fs.target @36.969s
└─remote-fs-pre.target @36.969s
└─iscsi-shutdown.service @36.965s
└─network.target @36.933s
└─wpa_supplicant.service @39.880s +1.095s
└─dbus.service @21.045s
└─basic.target @20.963s
└─sockets.target @20.963s
└─dbus.socket @20.963s
└─sysinit.target @20.911s
└─sys-fs-fuse-connections.mount @1min 32.526s +5ms
└─system.slice
└─-.slice
答案1
这plymouth-quit-wait.service就是您在屏幕上看到的内容，而其他服务正在启动。它只是被动地等待其他服务，这花费了太长时间。我会责怪dnf-makecache，systemd-journal-flush并且firewalld（你需要它们吗？为什么它们需要这么长时间？）
答案2
我刚刚读到dnf-makecache并systemd-journal-flush决定禁用它们；我认为我不需要那些。不过，我不确定 FirewallD 的情况。有更快的替代方案吗？我不知道为什么他们花了这么长时间，但我想禁用这两个会使速度更快。