Slow boot time

mutant · 2018-04-09 15:05:53

$ systemd-analyze blame

11.744s systemd-journal-flush.service
          9.147s lvm2-monitor.service
          8.712s dev-sda3.device
          5.039s lightdm.service
          3.616s systemd-fsck@dev-disk-by\x2dlabel-Home.service
          3.340s systemd-backlight@backlight:intel_backlight.service
          3.276s tlp.service
          3.192s NetworkManager.service
          2.928s systemd-fsck@dev-sda1.service
          1.896s accounts-daemon.service
          1.421s polkit.service
          1.398s systemd-logind.service
          1.395s bluetooth.service
          1.384s alsa-restore.service
          1.345s colord.service
          1.252s upower.service
          1.208s wpa_supplicant.service
          1.154s systemd-udevd.service
           766ms boot.mount
           618ms systemd-tmpfiles-setup-dev.service
           594ms dev-hugepages.mount
           565ms systemd-binfmt.service
           562ms dev-mqueue.mount
           555ms systemd-udev-trigger.service
           547ms sys-kernel-debug.mount
           515ms systemd-remount-fs.service
           513ms udisks2.service
           393ms systemd-journald.service
           378ms home.mount
           366ms user@1000.service
           317ms rtkit-daemon.service
           306ms proc-sys-fs-binfmt_misc.mount
           298ms sys-kernel-config.mount
           234ms kmod-static-nodes.service
           218ms systemd-sysctl.service
           202ms dev-sda2.swap
           177ms systemd-tmpfiles-clean.service
           165ms systemd-modules-load.service
           142ms systemd-random-seed.service
           128ms systemd-user-sessions.service
            98ms systemd-tmpfiles-setup.service
            77ms systemd-update-utmp.service
            19ms systemd-rfkill.service
            13ms sys-fs-fuse-connections.mount
            10ms tmp.mount

$ systemd-analyze time

Startup finished in 3.523s (firmware) + 188ms (loader) + 4.360s (kernel) + 23.639s (userspace) = 31.711s
graphical.target reached after 23.639s in userspace

$ 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 @23.639s
└─lightdm.service @18.598s +5.039s
  └─systemd-user-sessions.service @18.466s +128ms
    └─nss-user-lookup.target @21.381s

what should i do? i'm noob

Last edited by mutant (2018-04-10 09:28:07)

ewaller · 2018-04-09 15:22:06

Those times are not that bad; assuming you have a spinning hard drive and not an SSD.
Limiting your journal size would help. So would getting rid of your display manager.

My spinning hard disk system takes 17 seconds to reach the graphical target; about the same as yours. Then you wait another 5 seconds for the dunsel to start.

Edit: Oh, please edit your post to use BBCode code tags. https://bbs.archlinux.org/help.php#bbcode
That is the same link that is under every message post box on the forums for reference. Thanks.

Last edited by ewaller (2018-04-09 15:23:34)

mutant · 2018-04-10 09:31:48

so it's normal boot time? because i'm compared it with my manjaro before arch, manjaro faster start then arch

sorry for my english, i'm from indonesia

thank you

Last edited by mutant (2018-04-10 09:35:06)

rix · 2018-04-10 09:56:10

Using Google and Vi in /etc/systemd.

You're welcome.

Trilby · 2018-04-10 10:51:54

rix wrote:

Using Google and Vi in /etc/systemd.

What on earth does that mean? Posting "Your Welcome" afterwards suggests you are confident you just shared some groundbreaking knowledge that you are sure will solve the OPs problem. Yet what you shared is completely nonsensical.

ugjka · 2018-04-10 10:58:49

@trilby something to do with systemd using google dns servers. there was a fuss about it on the web. I suspect rix is some anti systemd guy

Trilby · 2018-04-10 11:01:21

*maybe*, but even then, it is so vague. Suggesting to "use Google" generally means search the web, and suggesting to use it, and a text editor, on a directory .... well that's just nonsense.

(And in case there is any anti-systemd sentiment here, this is really just the wrong battle to pick. I have countless philosophical gripes with systemd, but if the "proof is in the pudding" with respect to boot times, systemd just flat out destroys all the competition.)

Last edited by Trilby (2018-04-10 11:03:55)

ugjka · 2018-04-10 11:07:07

could be disorganized thinking, who knows, I think this is hijacking the thread

rix · 2018-04-10 12:23:39

Trilby wrote:

rix wrote:
Using Google and Vi in /etc/systemd.
What on earth does that mean? Posting "Your Welcome" afterwards suggests you are confident you just shared some groundbreaking knowledge that you are sure will solve the OPs problem. Yet what you shared is completely nonsensical.

Why so rough everytime? Anyway... you're right in some way, I should had be more... specific.

So, my previous message was in response to the Op when he asked how to limit Journal size as suggested by ewaller. Now, the Op have modified the message.

I meant that the Op should make some Google search before ask and that what he is trying to accomplish can be done editing files in /etc/systemd.

And at last, my "You're welcome" statement, was just answer to the Op "Thank you". Kindness.

Regards.

Last edited by rix (2018-04-10 12:46:45)

ugjka · 2018-04-10 12:31:41

it would've made sense if you said "use" instead of "using"... you completely flipped the meaning by using the wrong word

Last edited by ugjka (2018-04-10 12:32:50)

rix · 2018-04-10 12:48:08

@ugjka: thanks for the advice, english is not my native language.

seth · 2018-04-10 14:35:09

The output of "systemd-analyze critical-chain" looks far too short? And when it starts (nss-user-lookup.target @21.381s) you already lost quite some time. Raises the question whether nss-user-lookup.target is the (single) culprit and why it's enabled itfp. (vendor preset is disabled)

ewaller · 2018-04-10 14:51:57

And, back to the original thread....

mutant wrote:

so it's normal boot time? because i'm compared it with my manjaro before arch, manjaro faster start then arch
sorry for my english, i'm from indonesia
thank you

How fast did Manjaro boot? An order of magnitude faster? or a couple seconds faster?
Did your Manjaro installation have the same number of volumes mounted at startup, each requiring a fsck?
Was your Manjaro installation starting the same network interfaces? Using the same tools?

Another check; is your host name set correctly?
I note the nss-user-lookup.service. Are you using that? Please post the output of find /etc/systemd

TL;DR; I regard that as being fairly normal for a spinning hard disk. Does your system use a SSD, or a spinning hard disk?

Edit: Wow, Seth beat me by minutes.

Last edited by ewaller (2018-04-10 14:52:46)

Arch Linux

#1 2018-04-09 15:05:53

Slow boot time

#2 2018-04-09 15:22:06

Re: Slow boot time

#3 2018-04-10 09:31:48

Re: Slow boot time

#4 2018-04-10 09:56:10

Re: Slow boot time

#5 2018-04-10 10:51:54

Re: Slow boot time

#6 2018-04-10 10:58:49

Re: Slow boot time

#7 2018-04-10 11:01:21

Re: Slow boot time

#8 2018-04-10 11:07:07

Re: Slow boot time

#9 2018-04-10 12:23:39

Re: Slow boot time

#10 2018-04-10 12:31:41

Re: Slow boot time

#11 2018-04-10 12:48:08

Re: Slow boot time

#12 2018-04-10 14:35:09

Re: Slow boot time

#13 2018-04-10 14:51:57

Re: Slow boot time

Board footer