You are not logged in.
Hi All,
This is my first time posting to the forum. Apologies if I get this wrong...
As indicated in my subject line above, I am experiencing a 'long' boot time after a system-wide update (I used the 'sudo pacman -Syu' command, and proceeded to update as usual). On boot I notice the following message: "A start job is running on sys-subs...s-enp2s0.device" with a moving " * " and a counter in seconds up to 1min 30s proceeds. Only when the counter has reached the 90 seconds (1min30s) does boot continue successfully.
After reading a few other posts about similar boot time problems I ran the following commands with their corresponding outputs:
$ systemd-analyze critical-path
graphical.target @1min 31.177s
└─multi-user.target @1min 31.176s
└─smbd.service @1min 31.115s +60ms
└─nmbd.service @1min 31.012s +87ms
└─network.target @1min 30.998s
└─NetworkManager.service @1.503s +62ms
└─dbus.service @1.451s
└─basic.target @1.450s
└─sockets.target @1.449s
└─avahi-daemon.socket @1.449s
└─sysinit.target @1.445s
└─systemd-update-utmp.service @1.442s +2ms
└─systemd-tmpfiles-setup.service @1.431s +9ms
└─local-fs.target @1.430s
└─srv-nfs4-storage.mount @1.429s +1ms
└─storage.mount @1.345s +64ms
└─systemd-fsck@dev-disk-by\x2duuid-22e0aafe\x2d2f2
└─dev-disk-by\x2duuid-22e0aafe\x2d2f22\x2d4e73\x
$ systemd-analyze blame
289ms dev-sda1.device
176ms systemd-fsck@dev-disk-by\x2duuid-22e0aafe\x2d2f22\x2d4e73\x2db8
174ms systemd-journald.service
87ms nmbd.service
77ms polkit.service
65ms systemd-journal-flush.service
64ms storage.mount
63ms upower.service
62ms NetworkManager.service
61ms systemd-fsck@dev-disk-by\x2duuid-505520f9\x2d5527\x2d4a03\x2d84
60ms smbd.service
54ms alsa-restore.service
50ms systemd-udevd.service
47ms udisks2.service
38ms avahi-daemon.service
36ms systemd-modules-load.service
27ms accounts-daemon.service
25ms systemd-tmpfiles-setup-dev.service
24ms systemd-udev-trigger.service
22ms kmod-static-nodes.service
22ms systemd-remount-fs.service
22ms sys-kernel-debug.mount
22ms lm_sensors.service
20ms dev-mqueue.mount
17ms home.mount
17ms user@1000.service
14ms systemd-binfmt.service
13ms systemd-tmpfiles-clean.service
12ms colord.service
11ms dev-hugepages.mount
10ms dev-sda2.swap
9ms systemd-tmpfiles-setup.service
7ms systemd-sysctl.service
6ms systemd-user-sessions.service
6ms systemd-vconsole-setup.service
6ms proc-sys-fs-binfmt_misc.mount
5ms systemd-random-seed.service
4ms systemd-logind.service
2ms rtkit-daemon.service
2ms systemd-update-utmp.service
2ms nvidia-persistenced.service
2ms sys-fs-fuse-connections.mount
1ms tmp.mount
1ms sys-kernel-config.mount
1ms srv-nfs4-storage.mount
$ systemctl --failed
0 loaded units listed.
$ systemd-analyze
Startup finished in 1.444s (kernel) + 1min 31.177s (userspace) = 1min 32.622s
Can anyone help me resolve this long boot time please? Any help will be gratefully received!!
Best regards
Jon
Last edited by jonnyt43 (2016-10-21 16:18:04)
Offline
Offline
Dear loqs,
It worked!!
Thank you so much!
For anyone else with this issue, loqs's link indicated I needed to do the following:
$ cd /usr/lib/systemd/system
then
$ sudo nano systemd-user-sessions.service
which opens nano and has the following:
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
[Unit]
Description=Permit User Sessions
Documentation=man:systemd-user-sessions.service(8)
After=remote-fs.target nss-user-lookup.target network.target
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/lib/systemd/systemd-user-sessions start
ExecStop=/usr/lib/systemd/systemd-user-sessions stop
######
I then proceeded to delete "network.target" in the line that reads: "After= ..... network.target"
Made sure I wrote-out the changes and exited. I then rebooted, success, no delay!
SOLVED!!
Last edited by jonnyt43 (2016-10-21 16:19:36)
Offline
Just checking - is there a reason that you're editing the unit directly in /usr/lib/systemd/system?
Did you instead mean to do something like editing /etc/systemd/system/systemd-user-sessions.service.d/override.conf and setting as its contents:
[Unit]
After=
After=remote-fs.target nss-user-lookup.targetEdit: For reference (from the systemd arch wiki page): "To avoid conflicts with pacman, unit files provided by packages should not be directly edited."
Last edited by vyu223 (2016-10-23 18:40:14)
Offline
@vyu223 does that work for you?
Note that dependencies (After=, etc.) cannot be reset to an empty list,
so dependencies can only be added in drop-ins. If you want to remove
dependencies, you have to override the entire unit.
Which caused me to have to override the entire unit.
I agree about the path my post p1632295 after modification is meant to show that /usr/lib/systemd/system/systemd-user-sessions.service is incorrect hence the strike through and use /etc/systemd/system/systemd-user-sessions.service instead.
I did not want to simply replace the wrong path with the correct one and be accused of hiding my errors.
Offline
It does work for me! On my up-to-date system, that man page says the same thing for me as it does for you. Maybe it needs to be updated? I haven't looked into the commits for systemd to see if there was a change that started allowing this.
I do remember, though, that in one point in time, we were not allowed to clear the ExecStart array by doing "ExecStart=". And then some time later, we started being able to do it. Maybe something similar has happened for "After=".
I was originally directing my post toward the OP; I did notice in your post that you changed the path to /etc/systemd/system. Sorry for not being more clear.
EDIT: Huh. It must have been a fluke. I tried restarting today and had the original problem the OP had again. It looks like the man page is still accurate; the After array cannot be cleared by doing "After=". Overrode the whole unit (instead of using the drop in file) and have my system booting up fine now.
Last edited by vyu223 (2016-10-24 16:24:25)
Offline