Maybe it’s pcmanfm?
That’s what I’ve found:
https://bugzilla.redhat.com/show_bug.cgi?id=1797193
[eljejer@spectre ~]$ systemctl list-unit-files --state=enabled
UNIT FILE STATE VENDOR PRESET
org.cups.cupsd.path enabled disabled
autovt@.service enabled disabled
avahi-daemon.service enabled disabled
dbus-org.freedesktop.Avahi.service enabled disabled
dbus-org.freedesktop.nm-dispatcher.service enabled disabled
dbus-org.freedesktop.timesync1.service enabled disabled
display-manager.service enabled disabled
getty@.service enabled enabled
lightdm.service enabled disabled
NetworkManager-dispatcher.service enabled disabled
NetworkManager-wait-online.service enabled disabled
NetworkManager.service enabled disabled
optimus-manager.service enabled disabled
org.cups.cupsd.service enabled disabled
systemd-networkd-wait-online.service enabled disabled
systemd-timesyncd.service enabled enabled
tlp.service enabled disabled
avahi-daemon.socket enabled disabled
org.cups.cupsd.socket enabled disabled
remote-fs.target enabled enabled
20 unit files listed.
[eljejer@spectre ~]$
@eljejer
systemctl --failed
systemd-analyze blame
the dbus-org.freedesktop.nm-dispatcher.service is enabled
[eljejer@spectre ~]$ systemctl --failed
UNIT LOAD ACTIVE SUB DESCRIPTION
● session-7.scope loaded failed failed Session 7 of user eljejer
LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
1 loaded units listed.
systemd-analyze blame
1.327s optimus-manager.service
1.168s systemd-random-seed.service
624ms systemd-logind.service
573ms lvm2-monitor.service
501ms dev-nvme0n1p2.device
373ms systemd-timesyncd.service
315ms tlp.service
288ms systemd-udevd.service
273ms systemd-journald.service
130ms systemd-rfkill.service
127ms boot-efi.mount
79ms systemd-udev-trigger.service
63ms systemd-journal-flush.service
56ms accounts-daemon.service
52ms NetworkManager.service
51ms user@1000.service
49ms udisks2.service
44ms polkit.service
44ms modprobe@drm.service
41ms avahi-daemon.service
35ms systemd-fsck@dev-disk-by\x2duuid-eb0e1125\x2d4e7c\x2d46fd\x2d899f\x2dd81a5ee84a40.service
29ms systemd-fsck@dev-disk-by\x2duuid-9374\x2d9165.service
25ms org.cups.cupsd.service
21ms systemd-tmpfiles-setup-dev.service
18ms systemd-tmpfiles-setup.service
16ms systemd-tmpfiles-clean.service
15ms systemd-modules-load.service
11ms systemd-remount-fs.service
11ms lightdm.service
10ms systemd-backlight@backlight:intel_backlight.service
10ms systemd-sysctl.service
10ms home.mount
9ms dev-hugepages.mount
9ms user-runtime-dir@1000.service
9ms systemd-user-sessions.service
9ms dev-mqueue.mount
8ms sys-kernel-debug.mount
8ms systemd-update-utmp.service
8ms sys-kernel-tracing.mount
7ms wpa_supplicant.service
7ms tmp.mount
6ms kmod-static-nodes.service
4ms sys-fs-fuse-connections.mount
3ms rtkit-daemon.service
2ms proc-sys-fs-binfmt_misc.mount
2ms sys-kernel-config.mount
Maybe this update will fix my problem as well. The updated version of pcmanfm is not in the repo yet. I will be waiting for it then I presume
Even it’s enable could you try :
systemctl enable NetworkManager-dispatcher.service
systemctl start NetworkManager-dispatcher.service
then reboot
[eljejer@spectre ~]$ sudo systemctl enable NetworkManager-dispatcher.service
[sudo] password for eljejer:
[eljejer@spectre ~]$
I just remember yesterday @fernandomaroto gave an answer on this forum about slow time boot…
I rebooted while pcmanfm was opened and the reboot took about 2 mins (unusually long).
In my journal I see it timed out on stopping pcmanfm too, just as in yours. I am not normally using this file manager, so I set it to not load automatically (it does with the default EOS i3 config). Maybe try to use another file manager for now?
The problem is actually not during boot, but during shutdown issued by re-boot
Will do that. Thanks for your help!
1 Like
When @joekamprad would read this, he will give you a better answer on i3.
I think D-Bus is directly linked with Kernel, there is a blocked communication to resolve…or conflict with pcmanfm that is not new like would tell @FredBezies on another OS that name must not be spoken… 
1 Like
Thanks for all your help so far!
1 Like
april 17 06:28:36 spectre kernel: watchdog: watchdog0: watchdog did not stop!
april 17 06:28:36 spectre systemd[1]: Set hardware watchdog to 10min.
april 17 06:28:36 spectre systemd[1]: Hardware watchdog 'iTCO_wdt', version 0
Many users need this feature due to their system’s mission-critical role (i.e. servers), or because of the lack of power reset (i.e. embedded devices). Thus, this feature is required for a good operation in some situations. On the other hand, normal users (i.e. desktop and laptop) do not need this feature and can disable it.
To disable watchdog timers (both software and hardware), append nowatchdog to your boot parameters.
e.g. sudo nano /etc/default/grub
add nowatchdog to the kernel line like so:
GRUB_CMDLINE_LINUX_DEFAULT="quiet nowatchdog ..."
save [Ctrl+X]
rebuild grub.cfg:
sudo grub-mkconfig -o /boot/grub/grub.cfg
reboot
3 Likes
I had also installed i3wm and I’ve got a lot of errors with nouveau (in the log file).
Once Firefox refused to start so I had blacklisted nouveau and I’m just using the intel video card now
since then, all is fine 