You are not logged in.
Pages: 1
My system is taking a very long time to boot .
systemd-analyze gives
Startup finished in 7.748s (firmware) + 3.051s (loader) + 5.453s (kernel) + 48.736s (userspace) = 1min 4.989s
graphical.target reached after 48.735s in userspace
systemd-analyze blame gives
18.318s lightdm.service
17.576s systemd-journal-flush.service
14.612s lvm2-monitor.service
13.197s dev-sdb5.device
10.760s NetworkManager-wait-online.service
5.530s NetworkManager.service
4.992s systemd-udevd.service
4.088s polkit.service
3.979s bluetooth.service
3.852s systemd-logind.service
3.228s teamviewerd.service
2.400s systemd-tmpfiles-setup-dev.service
2.089s systemd-backlight@backlight:intel_backlight.service
1.504s wpa_supplicant.service
1.463s systemd-modules-load.service
1.257s accounts-daemon.service
1.038s systemd-binfmt.service
963ms systemd-tmpfiles-setup.service
948ms systemd-backlight@leds:dell::kbd_backlight.service
786ms systemd-udev-trigger.service
782ms udisks2.service
742ms systemd-sysctl.service
635ms kmod-static-nodes.service
632ms systemd-journald.service
609ms swapfile.swap
547ms tlp.service
546ms systemd-random-seed.service
523ms systemd-timesyncd.service
276ms sys-kernel-debug.mount
264ms systemd-remount-fs.service
264ms dev-hugepages.mount
263ms dev-mqueue.mount
254ms systemd-update-utmp.service
195ms user@1000.service
131ms systemd-user-sessions.service
36ms sys-kernel-config.mount
23ms rtkit-daemon.service
20ms proc-sys-fs-binfmt_misc.mount
15ms user-runtime-dir@1000.service
6ms tmp.mount
2ms sys-fs-fuse-connections.mount
Eg: on my firend's machine lvm2-monitor.service takes about 4.5s
I got 16G ram and an Intel i7 7th gen so i wonder what is going on?
Last edited by spandan2 (2019-01-17 15:18:51)
Offline
That systemd-analyze output doesn't mean much of anything. Please post a bootchart or `systemd-analyze critical-chain` output.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Online
That systemd-analyze output doesn't mean much of anything. Please post a bootchart or `systemd-analyze critical-chain` output.
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 @46.230s
`-lightdm.service @27.539s +18.689s
`-systemd-user-sessions.service @27.466s +72ms
`-network.target @27.465s
`-wpa_supplicant.service @31.464s +1.995s
`-basic.target @21.771s
`-sockets.target @21.771s
`-dbus.socket @21.771s
`-sysinit.target @21.771s
`-systemd-timesyncd.service @21.205s +566ms
`-systemd-tmpfiles-setup.service @20.541s +507ms
`-systemd-journal-flush.service @5.147s +15.391s
`-systemd-journald.service @4.850s +295ms
`-systemd-journald-audit.socket @4.848s
`-system.slice @3.648s
`--.slice @3.648s
Last edited by spandan2 (2019-01-12 21:44:35)
Offline
PLease use code tags when pasting to the boards: https://wiki.archlinux.org/index.php/Co … s_and_code
Offline
PLease use code tags when pasting to the boards: https://wiki.archlinux.org/index.php/Co … s_and_code
Thanks! I'll keep that in mind from now onwards
Offline
So most of that time is just logging in at your display manager. The journal flush seems to have taken quite a bit - is it like that on every boot or was that a one-off issue?
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Online
So most of that time is just logging in at your display manager. The journal flush seems to have taken quite a bit - is it like that on every boot or was that a one-off issue?
Every single boot. I tried changing DMs.. No improvement..
Last edited by spandan2 (2019-01-13 03:12:08)
Offline
This is from today
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 @51.030s
`-lightdm.service @33.917s +17.113s
`-systemd-user-sessions.service @33.881s +34ms
`-network.target @33.880s
`-wpa_supplicant.service @37.886s +1.926s
`-basic.target @28.720s
`-sockets.target @28.720s
`-dbus.socket @28.720s
`-sysinit.target @28.683s
`-systemd-update-done.service @28.636s +46ms
`-ldconfig.service @18.143s +10.490s
`-local-fs.target @18.139s
`-local-fs-pre.target @18.139s
`-lvm2-monitor.service @5.116s +13.022s
`-lvm2-lvmetad.service @6.704s
`-lvm2-lvmetad.socket @5.111s
`-system.slice @3.778s
`--.slice @3.778s
-lvm2-monitor.service is not looking good too
Last edited by spandan2 (2019-01-13 04:03:22)
Offline
The journal flush is not there on that output.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Online
After disabling lightdm I get
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 @35.551s
`-multi-user.target @35.551s
`-teamviewerd.service @33.315s +2.234s
`-network-online.target @33.314s
`-NetworkManager-wait-online.service @22.262s +11.051s
`-NetworkManager.service @17.323s +4.938s
`-dbus.service @17.321s
`-basic.target @17.097s
`-sockets.target @17.097s
`-dbus.socket @17.097s
`-sysinit.target @17.052s
`-systemd-backlight@backlight:intel_backlight.service @15.030s +2.022s
`-system-systemd\x2dbacklight.slice @11.823s
`-system.slice @3.289s
`--.slice @3.289s
Offline
The journal flush is not there on that output.
Isn't the boot time still quite high?
Offline
The limiting factor in post #10 sems teamviewer which waits for an established network connection and NM seems to take 15 seconds to get there.
Since there're wpa_supplicant services in the other chains (but not NM ones):
systemctl list-unit-files --state=enabled
And
journalctl -b
to get a better idea what's going on there.
Online
Isn't the boot time still quite high?
Yes. But to get to the bottom of why it is taking long, we need reliable data. When asked a direct yes or no question about a particular detail behind the problem, you provided incorrect information. That makes it very hard to proceed. If it indeed was journal flushing occurring on every boot and taking a long time, we would have pinpointed the problem - but this is not the case, so the problem lies elsewhere.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Online
The limiting factor in post #10 sems teamviewer which waits for an established network connection and NM seems to take 15 seconds to get there.
Since there're wpa_supplicant services in the other chains (but not NM ones):systemctl list-unit-files --state=enabled
And
journalctl -b
to get a better idea what's going on there.
Thanks a lot disabling teamviewerd.service solved the issue
Offline
Please remember to mark your thread [SOLVED] (edit the title of your first post).
How to post. A sincere effort to use modest and proper language and grammar is a sign of respect toward the community.
Offline
Pages: 1