Re: much longer boot time with jessie
Quoting Fekete Tamás (fektom@gmail.com):
>>> I have 7 years old computer with wheezy installed on it. Temporarly or not I
>>> decided to keep this older version of Debian, because I upgraded to jessie and
>>> the boot time became extremey slower. To represent this with numbers: when grub
>>> finished with countdown, took 52 seconds to boot into GDM.
>>> In wheezy it tooks only 30 sec (which is completely normal I think) with the
>>> same conditions.
My experience is similar on this 7 year old laptop. Typical timings:
jessie wheezy
1 Grub to Login Prompt 82 47
2 Login Prompt to VC Bash Prompt 33 6
3 Bash Command to X fully up 62 16
2 and 3 are faster if repeated after all the startup disk activity has
subsided.
1 usually takes an infinite time if the module binfmt_misc is
not loaded from /etc/modules. (See
https://lists.debian.org/debian-user/2015/05/msg01060.html
and follow the In-reply-to or References links.
> So, firstly the slowlyness was not because of the first boot (because I tried
> more than 10times)
> Secondly, I can not say how the system would act for commands given by Michael
> (because
> I moved back to wheezy)
Here's the output for this laptop:
$ systemd-analyze blame
1min 27.935s ModemManager.service
1min 13.144s acpi-support.service
52.112s avahi-daemon.service
46.983s ntp.service
26.242s wicd.service
20.986s exim4.service
19.930s timidity.service
17.381s console-kit-daemon.service
16.372s binfmt-support.service
16.274s alsa-restore.service
16.273s console-kit-log-system-start.service
15.918s bluetooth.service
15.663s lm-sensors.service
15.303s systemd-logind.service
15.206s rc-local.service
15.202s systemd-user-sessions.service
15.200s apmd.service
15.199s rsyslog.service
15.199s virtualbox.service
15.199s loadcpufreq.service
15.198s gpm.service
11.174s colord.service
9.694s aumix.service
8.227s user@1000.service
7.388s polkitd.service
7.365s systemd-suspend.service
4.271s keyboard-setup.service
3.677s systemd-fsck@dev-disk-by\x2dlabel-john03.service
3.674s networking.service
3.618s kbd.service
2.958s nfs-common.service
2.916s systemd-modules-load.service
2.548s irqbalance.service
2.469s systemd-tmpfiles-setup-dev.service
2.342s resolvconf.service
2.199s systemd-tmpfiles-setup.service
2.019s systemd-setup-dgram-qlen.service
2.015s dev-hugepages.mount
1.926s dev-mqueue.mount
1.849s systemd-fsck@dev-disk-by\x2dlabel-john02.service
1.841s sys-kernel-debug.mount
1.829s hdparm.service
1.475s rpcbind.service
1.437s systemd-udev-trigger.service
1.415s gdomap.service
1.233s saned.service
1.164s cpufrequtils.service
868ms dev-disk-by\x2dlabel-john04.swap
654ms westw.mount
640ms kmod-static-nodes.service
545ms systemd-update-utmp.service
528ms systemd-udevd.service
512ms systemd-remount-fs.service
431ms rtkit-daemon.service
424ms systemd-backlight@backlight:intel_backlight.service
312ms systemd-rfkill@rfkill1.service
305ms systemd-rfkill@rfkill0.service
286ms systemd-sysctl.service
286ms systemd-rfkill@rfkill4.service
274ms systemd-rfkill@rfkill3.service
243ms systemd-tmpfiles-clean.service
237ms systemd-backlight@backlight:dell_backlight.service
195ms systemd-rfkill@rfkill2.service
120ms console-setup.service
109ms clamav-daemon.socket
95ms systemd-random-seed.service
91ms udev-finish.service
42ms home.mount
19ms proc-sys-fs-binfmt_misc.mount
12ms systemd-rfkill@rfkill5.service
12ms systemd-journal-flush.service
11ms systemd-update-utmp-runlevel.service
5ms sys-fs-fuse-connections.mount
$ 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 @2min 6.738s
└─multi-user.target @2min 6.738s
└─acpi-support.service @53.593s +1min 13.144s [in RED]
└─basic.target @37.647s
└─sockets.target @37.643s
└─clamav-daemon.socket @37.530s +109ms [in RED]
└─sysinit.target @37.517s
└─systemd-journald.service @1min 50.051s
└─syslog.socket @6.791s
└─systemd-setup-dgram-qlen.service @4.768s +2.019s [in RED]
└─system.slice @4.766s
└─-.slice @4.764s
> The only thing I can add to this topic that the problem came not because of a
> bad apt-get dist-upgrade, because boot was slowly even if I installed a
> completely new jessie.
That's depressing. I had thought that a fresh install (instead of a
squeeze/wheezy upgrade) might improve things.
I would normally install a fresh jessie on the partition john02/westw
seen above, but its wheezy installation is my only working bluetooth
link to get the pictures off my dumbest mobiles, so I can't afford to
lose it.
> Based on your answers, it seems my problem is an exception and not the rule.
> But it seems something is not okay with the new jessie, that's sure.
...or the kernel that comes with it. Anything that involves the disk
is slower (and slower than wheezy) the first time (ie not cached).
I have wondered whether the parallelisation achieved by systemd is
counterproductive, and that I might be better off trying to stick with
SysV.
Cheers,
David.
Reply to: