Kernel taking more than 12 seconds to load.

jonnsl · 2015-01-16 04:59:22

Hi,
systemd-analyze says my computer is taking 12.395s to load the kernel, which I think is a little bit too much, maybe the kernel is trying to do something than giving up after a 10 seconds timeout.
How do I proceed to debugging this?

WonderWoofy · 2015-01-16 05:13:00

Does your output for systemd-analyze include 'kernel', 'initrd', and 'usersapce'? Or do you simply have 'kernel' and 'userspace'?

If you have no time recorded for the initrd, then the kernel time also includes the initrd time as well. You can get it to report the initrd time if you use systemd in the initramfs instead of the base and udev hooks.

jonnsl · 2015-01-16 05:37:25

WonderWoofy wrote:

Does your output for systemd-analyze include 'kernel', 'initrd', and 'usersapce'? Or do you simply have 'kernel' and 'userspace'?
If you have no time recorded for the initrd, then the kernel time also includes the initrd time as well.

it doesn't include initrd, just:Startup finished in 12.395s (kernel) + 11.742s (userspace) = 24.137s

WonderWoofy wrote:

You can get it to report the initrd time if you use systemd in the initramfs instead of the base and udev hooks.

how exactly do I do this?
I assume that I need to change /etc/mkinitcpio.conf, from:
HOOKS="base udev autodetect modconf block lvm2 filesystems keyboard fsck"
to: HOOKS="systemd autodetect modconf block lvm2 filesystems keyboard fsck"
and than running `# mkinitcpio -p linux`. is this correct?

WonderWoofy · 2015-01-16 06:08:47

That is exactly what you need to do.

jonnsl · 2015-01-16 06:51:12

done, I also removed the lvm2 hook (I misread the wiki and thought that I needed the lvm2 hook but it is only needed if the root is on lvm which is not, just some folders on home.), which was probably the cause of the problem.
systemd-analyze now:
Startup finished in 552ms (kernel) + 3.834s (initrd) + 13.624s (userspace) = 18.011s
thank you very much for the help.

mrunion · 2015-01-16 20:15:31

Just a quick question on removing base and udev from HOOKS and replacing with systemd: Is this a normal thing one would do, or is it a debug/test thing, and one should not run this way on a day to day system? Or is it a speed thing?

WonderWoofy · 2015-01-17 03:27:25

@mrunion, it just basically uses systemd as /sbin/init in the initramfs instead of a script. It seems to me that we trust systemd to be the process manager for our machines, so if it is capable of getting through the initramfs stage of the boot process, why not let it do that too. I have been using it since it was introduced as an option in mkinitcpio and it seems to work great. I would imagine that it would handle itself better with ordering dependencies than a script would. So if you use things like lvm2, mdadm, or encryption it would likely be beneficial.

Trilby · 2015-01-17 03:34:35

MODULES="ahci sd_mod ext4"
BINARIES="fsck fsck.ext4"
FILES=""
HOOKS="systemd"
COMPRESSION=cat

Startup finished in 407ms (kernel) + 975ms (initrd) + 1.951s (userspace) = 3.334s

:)

mrunion · 2015-01-18 15:15:44

I see. I think I'll give that a try! Thanks for the explaination.

Also, FWIW, my systemd-analyze seems to be pretty bad compared to some people:

Startup finished in 5.733s (firmware) + 2.623s (loader) + 2.018s (kernel) + 18.274s (userspace) = 28.649s

Last edited by mrunion (2015-01-18 15:17:11)

smirky · 2015-01-18 16:28:02

Startup finished in 4.628s (kernel) + 36.505s (userspace) = 41.133s

But I have lots of daemons running so I guess it's normal.

$ grep "^MODULES\|^BINARIES\|^FILES\|^HOOKS" mkinitcpio.conf 
MODULES=""
BINARIES=""
FILES=""
HOOKS="base udev autodetect modconf block lvm2 filesystems keyboard fsck"

    1min 12.733s updatedb.service
         21.940s man-db.service
         19.332s mysqld.service
         13.554s httpd.service
         11.049s nmbd.service
         10.667s postfix.service
          9.409s wicd.service
          4.134s lvm2-pvscan@8:18.service
          3.988s logrotate.service
          3.615s thermald.service
          2.852s saslauthd.service
          2.823s systemd-fsck@dev-disk-by\x2duuid-45af176e\x2d5290\x2d4632\x2dbb53\x2d50842f6c7822.service
          2.601s systemd-journal-flush.service
          2.073s opendkim.service
          1.829s systemd-fsck@dev-disk-by\x2duuid-8258da30\x2dedab\x2d4de7\x2da9ef\x2de5ac9b81d47e.service
          1.716s alsa-restore.service
          1.661s systemd-fsck@dev-disk-by\x2duuid-8be9462b\x2de8af\x2d4199\x2d88e1\x2d97e14177b0ff.service
          1.655s systemd-fsck@dev-disk-by\x2duuid-10ee4fdc\x2d8e9d\x2d419c\x2d9e08\x2dd63be29732db.service
          1.633s cpupower.service
          1.458s boot.mount
          1.271s opt.mount
          1.202s proftpd.service
          1.070s rpcbind.service
          1.039s systemd-fsck@dev-disk-by\x2duuid-7143c2cb\x2d98c7\x2d4f36\x2d91f4\x2d741728ccb553.service
           927ms systemd-user-sessions.service
           902ms systemd-modules-load.service
           833ms netctl.service
           824ms systemd-logind.service
           798ms lm_sensors.service
           736ms systemd-journald.service
           716ms ntpd.service
           628ms mnt-sdc.mount
           627ms systemd-binfmt.service
           621ms tmp.mount
           621ms dev-mqueue.mount
           589ms dev-hugepages.mount
           580ms systemd-remount-fs.service
           545ms sys-kernel-debug.mount
           516ms proc-sys-fs-binfmt_misc.mount
           489ms systemd-vconsole-setup.service
           472ms systemd-tmpfiles-setup-dev.service
           431ms syslog-ng.service
           427ms dev-disk-by\x2duuid-0b3e2163\x2dd466\x2d4322\x2daf20\x2d38a5a671a6a3.swap
           424ms systemd-udevd.service
           422ms systemd-rfkill@rfkill0.service
           413ms systemd-random-seed.service
           412ms systemd-udev-trigger.service
           384ms polkit.service
           370ms shadow.service
           330ms var.mount
           321ms systemd-tmpfiles-clean.service
           303ms udisks.service
           248ms avahi-daemon.service
           178ms udisks2.service
           159ms kmod-static-nodes.service
           158ms home.mount
           146ms user@1000.service
           105ms systemd-sysctl.service
            95ms upower.service
            72ms systemd-tmpfiles-setup.service
            40ms systemd-update-utmp.service
            36ms sys-kernel-config.mount
           983us sys-fs-fuse-connections.mount

Last edited by smirky (2015-01-18 16:32:58)

China-LOL · 2015-01-21 08:49:06

learning

Arch Linux

#1 2015-01-16 04:59:22

Kernel taking more than 12 seconds to load.

#2 2015-01-16 05:13:00

Re: Kernel taking more than 12 seconds to load.

#3 2015-01-16 05:37:25

Re: Kernel taking more than 12 seconds to load.

#4 2015-01-16 06:08:47

Re: Kernel taking more than 12 seconds to load.

#5 2015-01-16 06:51:12

Re: Kernel taking more than 12 seconds to load.

#6 2015-01-16 20:15:31

Re: Kernel taking more than 12 seconds to load.

#7 2015-01-17 03:27:25

Re: Kernel taking more than 12 seconds to load.

#8 2015-01-17 03:34:35

Re: Kernel taking more than 12 seconds to load.

#9 2015-01-18 15:15:44

Re: Kernel taking more than 12 seconds to load.

#10 2015-01-18 16:28:02

Re: Kernel taking more than 12 seconds to load.

#11 2015-01-21 08:49:06

Re: Kernel taking more than 12 seconds to load.

Board footer