Pacman-init.service takes long time at boot recently

Hello everybody.
I'm experiencing since yesterday a higher time for booting (I know, it's silly, but being new to Garuda I still like checking systemd-analyze daily).
It used to be 17-20s and now 35-40s, always and only due to pacman-init.service taking 25-30s.
I searched in the forum, in the Arch forum and the Internet in general, but I wasn't able to find anything useful for me.
All the services are running, pacman-init.service executes and exits without errors.
Yesterday the sudo pacman -Syu upgraded the following (taken from pacman.log):

[2021-04-05T21:37:51+0200] [ALPM] upgraded systemd-libs (248-2 -> 248-3)
[2021-04-05T21:37:51+0200] [ALPM] upgraded bluez (5.57-1 -> 5.58-1)
[2021-04-05T21:37:51+0200] [ALPM] upgraded cryptsetup (2.3.5-1 -> 2.3.5-2)
[2021-04-05T21:37:52+0200] [ALPM] upgraded systemd (248-2 -> 248-3)
[2021-04-05T21:37:54+0200] [ALPM] upgraded run-parts ( -> 4.11.2-1)
[2021-04-05T21:37:54+0200] [ALPM] upgraded sqlite (3.35.3-1 -> 3.35.4-1)
[2021-04-05T21:37:54+0200] [ALPM] upgraded poppler (21.03.0-1 -> 21.04.0-1)
[2021-04-05T21:37:54+0200] [ALPM] upgraded bluez-cups (5.57-1 -> 5.58-1)
[2021-04-05T21:37:54+0200] [ALPM] upgraded bluez-hid2hci (5.57-1 -> 5.58-1)
[2021-04-05T21:37:54+0200] [ALPM] upgraded bluez-libs (5.57-1 -> 5.58-1)
[2021-04-05T21:37:54+0200] [ALPM] upgraded bluez-plugins (5.57-1 -> 5.58-1)
[2021-04-05T21:37:55+0200] [ALPM] upgraded bluez-utils (5.57-1 -> 5.58-1)
[2021-04-05T21:37:55+0200] [ALPM] warning: /etc/pacman.d/mirrorlist installed as /etc/pacman.d/mirrorlist.pacnew
[2021-04-05T21:37:55+0200] [ALPM] upgraded pacman-mirrorlist (20210302-1 -> 20210405-1)

I also tried to apply checks from the below FAQ, but with no luck:

Although this is for sure not urgent nor critical, any hint/help would be much appreciated.

Post please ^^^

22.533s pacman-init.service
5.153s systemd-swap.service
4.843s linux-modules-cleanup.service
3.686s ananicy.service
2.033s smb.service
1.678s lvm2-monitor.service
1.674s dev-sda5.device
1.596s polkit.service
1.447s systemd-logind.service
1.315s ModemManager.service
1.021s NetworkManager.service
735ms [email protected]
724ms avahi-daemon.service
648ms cups.service
632ms systemd-random-seed.service
585ms upower.service
551ms systemd-guest-user.service
418ms rtkit-daemon.service
353ms systemd-udev-trigger.service
310ms systemd-remount-fs.service
305ms udisks2.service
299ms dev-zram0.swap
297ms systemd-vconsole-setup.service
290ms dev-zram1.swap
262ms [email protected]
232ms bluetooth.service
218ms [email protected]\x2duuid-C86F\x2dB725.service

Disable pacman-init.service it should not be running IMO.


Actually @dr460nf1r3 Enabled it by default

We have lots of issues with the PGP keys currently which could be solved by these systemd services maybe as it initializes the keyring on each boot, opinions?

╭─[email protected] in ~ took 154ms
╰─λ cat /etc/systemd/system/pacman-init.service
File: /etc/systemd/system/pacman-init.service
# SPDX-License-Identifier: GPL-3.0-or-later

Description=Initializes Pacman keyring

ExecStart=/usr/bin/pacman-key --init
ExecStart=/usr/bin/pacman-key --populate chaotic
ExecStart=/usr/bin/pacman-key --populate archlinux


and the other one
╰─λ cat /etc/systemd/system/etc-pacman.d-gnupg.mount
File: /etc/systemd/system/etc-pacman.d-gnupg.mount
# SPDX-License-Identifier: GPL-3.0-or-later

Description=Temporary /etc/pacman.d/gnupg directory



Yes indeed, enabled it to prevent those countless posts regarding gpg key issues. Once we have new builders this will inevitably happen again as they use different keys to sign the packages :eyes:


Thanks to all!
For now, I'll disable it, knowing now that it could come in handy in case of PGP issues!

Well, I just tested bootup time, no noticable change of the time taken for reaching the desktop - yes, pacman-init still runs after reaching the desktop but thats only noticed by people running systemd-analyse blame . So I dont really feel the need to change that.


OK, I see.
So probably the time to reach the desktop is not changing (or at least changing much) for me too and that service continued in parallel after reaching the desktop.
So maybe I just discovered it doing the systemd-analyze and then blame due to the changed time, but as I said above "not a big issue" (now I understand why I didn't feel it as such :slight_smile: ).

Sorry if I spoke out of turn, I didn't realize you guys had it enabled by default for that reason. Any posts on the Arch forum regarding the service seemed to indicate it was not needed on a system once installed.