For some months now, when fully restarting my PC and logging into manjaro it takes about 3-5 minutes for it to finish. It is just stuck in the “Enter password” screen once I enter it correctly and works just fine after.
Does someone have an idea why this might happen?
The most common culprit is a no longer compatible theme or widget. On the other hand, you may also want to check your Autostart settings, as well as the Baloo indexing.
Worst case scenario, your Plasma configuration files have gotten corrupted. You can try debugging that by first deleting your cache while not logged into Plasma yet — you have to do it from a tty. 
rm -rf ~/.cache/*
If this does not improve the situation, then you may have to nuke your entire Plasma configuration and start all over again with the default setup, and then take it from there. (Been there, done that, have the T-shirt…)
Yup, next step try mv ~/.config ~/.configBK then log out and in again, desktop should be a little more vanilla - then open side by side and move stuff back bit by bit logging out/in again as you do (most config folders for software shouldn’t have any effect - but it can).
I just ran rm -rf ~/.cache/* from a tty, have baloo indexing disabled afaik. because it was pretty slow and took up a lot of memory and only have “matray” in Autostart
In that case, it could be an incompatible theme and/or widget, or simply spurious config file corruption, and in that case, I will point at @Ben’s advice of renaming your ~/.config and ~/.local directories, starting from a vanilla setup again — or from a working backup copy — and then comparing your Plasma-related files against the ones in the renamed directories.
You can probably put back the application-specific configuration directories — e.g. for your browser(s), email, multimedia player(s), et al — without much trouble, but Plasma itself does tend to, um, soil itself from time to time, and I’ve had that happening to myself several times in a row now since we moved to 5.27.8 a couple of months ago. Luckily I’ve got backups.
Hopefully 5.27.9 — currently freshly entering the Manjaro Testing branch as of today — will reintroduce the stability 5.27 was known for earlier. 
Instead of starting with changing things in your current profile, you might want to simply create a new test user. You should login to that user twice as the first login might need some initialization steps. If the second login procedure runs faster than with your current login, you have proof that it is caused by your current configuration.
If you’re using an SSD, then baloo shouldn’t make much impact… but there’s no harm in trimming/deleting db/restarting it to see if it improves things. There were a lot of folks talking about it in the past, but I haven’t had a problem with it for several years. Those text files and dot files are another matter - and sometimes just clearing them fixes - as @Aragorn puts it so eloquently, KDE sometimes poops it’s own nappy.
I have it set to my home directory, plus directories across 3 hard drives for Audio/Music/Books/TV folders/Movie folders - so my menu pulls up just about anything I’m looking for.
As suggested - I always log in to my TEST desktop first of all, and then do the re-import of my .config and .local and other hidden gremlins.
It’s surprising how much you can leave behind, and as long as you have some snapshots/backups there’s no fear of losing stuff.
The error persists even when logging into another user
What’s the output of…
systemd-analyze blame
…?
8.098s pkgfile-update.service
6.878s NetworkManager-wait-online.service
2.560s systemd-modules-load.service
1.702s systemd-tmpfiles-clean.service
854ms alsa-restore.service
756ms NetworkManager.service
690ms dev-nvme0n1p2.device
644ms systemd-tmpfiles-setup.service
475ms docker.service
398ms dev-loop7.device
397ms dev-loop6.device
395ms dev-loop8.device
394ms dev-loop5.device
391ms dev-loop4.device
389ms dev-loop2.device
388ms dev-loop0.device
388ms dev-loop1.device
387ms dev-loop3.device
262ms systemd-udev-trigger.service
242ms systemd-remount-fs.service
236ms systemd-binfmt.service
198ms user@1000.service
177ms snapd.service
175ms modprobe@fuse.service
164ms upower.service
156ms modprobe@drm.service
139ms polkit.service
133ms containerd.service
128ms systemd-journal-flush.service
121ms lvm2-monitor.service
120ms boot-efi.mount
112ms systemd-backlight@leds:dell::kbd_backlight.service
107ms systemd-vconsole-setup.service
70ms cups.service
67ms systemd-tmpfiles-setup-dev-early.service
66ms systemd-fsck@dev-disk-by\x2duuid-B461\x2d3A56.service
66ms systemd-timesyncd.service
65ms kmod-static-nodes.service
64ms modprobe@configfs.service
64ms systemd-update-utmp.service
61ms systemd-logind.service
60ms systemd-udevd.service
60ms ModemManager.service
59ms libvirtd.service
56ms systemd-user-sessions.service
55ms logrotate.service
52ms modprobe@loop.service
51ms udisks2.service
50ms avahi-daemon.service
49ms bluetooth.service
47ms cockpit-motd.service
46ms systemd-backlight@backlight:intel_backlight.service
46ms systemd-sysctl.service
46ms systemd-tmpfiles-setup-dev.service
45ms systemd-journald.service
43ms user-runtime-dir@1000.service
42ms dbus.service
42ms systemd-machined.service
37ms accounts-daemon.service
34ms systemd-random-seed.service
34ms ufw.service
20ms eruption-hotplug-helper.service
20ms eruption.service
17ms cockpit.socket
15ms var-lib-snapd-snap-core22-858.mount
14ms proc-sys-fs-binfmt_misc.mount
14ms var-lib-snapd-snap-core22-864.mount
14ms rtkit-daemon.service
13ms var-lib-snapd-snap-cqtdeployer-270.mount
13ms var-lib-snapd-snap-core20-2015.mount
12ms var-lib-snapd-snap-cqtdeployer-271.mount
11ms var-lib-snapd-snap-snapcraft-9542.mount
10ms dev-hugepages.mount
10ms var-lib-snapd-snap-snapcraft-9726.mount
10ms wpa_supplicant.service
9ms dev-mqueue.mount
9ms sys-kernel-debug.mount
8ms var-lib-snapd-snap-snapd-20092.mount
8ms sys-kernel-tracing.mount
7ms var-lib-snapd-snap-snapd-20290.mount
4ms systemd-rfkill.service
4ms docker.socket
3ms swapfile.swap
3ms nordvpnd.socket
2ms sys-fs-fuse-connections.mount
2ms var-lib-snapd-snap.mount
2ms modprobe@dm_mod.service
2ms sys-kernel-config.mount
1ms tmp.mount
460us snapd.socket
I don’t really see anything out of the ordinary there, other than that it could be mildly optimized, but there’s nothing there to account for the enormous delays you say you experience. 
Agree, it definitely takes more than 15s, its more like 3 minutes
This shouldnt exist.
It arguably should have never existed … but it was finally removed from manjaro sometime last year?
It doesnt exist in the repos anymore … and should not be on your system.
systemctl status pkgfile-update
I honestly forget what package(s) it would be tied to … so more info might be helpful.
I just uninstalled pkgfile, which had been installed in 2020 & contained the pkgfile-update service.
pkgfile: command-not-found hook is still listed in Pamac as an optional dependency of fish, which I had installed earlier this year.
Huh. I must have typod my search.
$ sudo pacman -Fyx 'pkgfile-update'
extra/pkgfile 21-2
usr/lib/systemd/system/pkgfile-update.service
usr/lib/systemd/system/pkgfile-update.timer
So there it is.
But what I said about it previously being included and since being replaced is still true.
As is the idea that it is unnecessary overhead for a providing an inferior version of functions already provided* - meaning pkgfile and its related services are worse than useless.
As well as being at the top of systemd-analyze blame for OP here.
(* pkgfile creates its own database and checks that against commands in terminal to see about ‘command not found’ - introducing noticeable lag in general use. And thats not counting the bakcround service and timers. pacman already provides a package database, as well as a timer for updating it. There are multiple approaches for using this to provide a ‘command not found’ feature if that is desirable.)
Has been recently replaced with pacman-filesdb-refresh.service and pacman-filesdb-refresh.timer.
so I am supposed to pacman -Rs pkgfile-update?
The package is pkgfile
Systemd-analyze measures until the graphical.target but your delay comes afterwards.
You might be more successful checking the journal with journalctl to see what’s happening.
From experience, these delays come from mounted network volumes that are unreachable and it waits for the timeout to continue.
The login seems to work just fine when choosing wayland instead of x11 (sadly this doesn’t solve the issue because I can’t use wayland due to multiple issues with it)