This happened since I updated, it hangs on this line for the full 1 min and 30 seconds max. Can I at least reduce the max time? I didnt install EndeavourOS to my nvme drive to have to wait this kind of time during boot.
Not sure what you mean here? Do you mean this is happening just booting the live ISO?
Not that I would know how to resolve the issue, but I would start by looking at the journals to see if it reveals anything relevant about the process holding up the shutdown.
You could for example reboot the system and when it is back up, open a terminal and run:
journalctl --since "N min ago" --no-pager > journal.txt
replacing N with an appropriate number depending on when you issued the reboot.
Then open the text file and look for something like:
systemd-logind[817]: The system will reboot now!
and take it from there.
Look for where the rebooting process is halted and see if it gives you more details about what is going on.
1 Like
Looks like there’s a problem with udevd service, after booting, check the unit log :
journalctl --since "10 min ago" -u systemd-udevd.service
i noticed a delay with the same message on my system its not something extreme like OP delaying boot for 5 minutes but…
âžś ~ journalctl --since "10 min ago" -u systemd-udevd.service
jul 20 09:56:33 systemd[1]: Starting Rule-based Manager for Device Events and Files...
jul 20 09:56:33 systemd-udevd[329]: Using default interface naming scheme 'v255'.
jul 20 09:56:33 systemd[1]: Started Rule-based Manager for Device Events and Files.
jul 20 09:56:34 systemd[1]: Stopping Rule-based Manager for Device Events and Files...
jul 20 09:56:41 systemd[1]: systemd-udevd.service: Deactivated successfully.
jul 20 09:56:41 systemd[1]: Stopped Rule-based Manager for Device Events and Files.
jul 20 09:56:42 systemd[1]: Starting Rule-based Manager for Device Events and Files...
jul 20 09:56:42 systemd-udevd[514]: Using default interface naming scheme 'v255'.
jul 20 09:56:42 systemd[1]: Started Rule-based Manager for Device Events and Files.
jul 20 09:56:42 mtp-probe[582]: checking bus 1, device 3: "/sys/devices/pci0000:00/0000:00:02.1/0000:04:0>
jul 20 09:56:42 mtp-probe[580]: checking bus 1, device 4: "/sys/devices/pci0000:00/0000:00:02.1/0000:04:0>
jul 20 09:56:42 mtp-probe[583]: checking bus 1, device 2: "/sys/devices/pci0000:00/0000:00:02.1/0000:04:0>
jul 20 09:56:42 mtp-probe[581]: checking bus 1, device 5: "/sys/devices/pci0000:00/0000:00:02.1/0000:04:0>
jul 20 09:56:43 mtp-probe[583]: bus: 1, device: 2 was not an MTP device
jul 20 09:56:43 mtp-probe[581]: bus: 1, device: 5 was not an MTP device
jul 20 09:56:43 mtp-probe[582]: bus: 1, device: 3 was not an MTP device
jul 20 09:56:43 mtp-probe[580]: bus: 1, device: 4 was not an MTP device
any ideas what could be doing this delay?
Check if might have some odd rule in /etc/udev/rules.d/
yeah there’s a rule related to my mouse https://github.com/dokutan/mouse_m908/blob/master/mouse_m908.rules but should this cause a delay of 5 seconds? it started like 2 or 3 weeks ago, i installed it from AUR 4 months ago hmm…
You installed what? It was just a suggestion to check in case something odd.
https://aur.archlinux.org/packages/mouse_m908 this is the only thing located in udev/rules.d/ 
i will see if removing solve this delay.
I also have a file there too but is for a printer. I might remove it also because i don’t have the printer anymore.
There’s no delay, nothing wrong with 10s (09:56:33 to 09:56:43) for starting the service.
Please open your own thread to troubleshoot your issue.
Even though the “symptom” of the issue may seem similar, the cause of it might be different.
Thanks!
1 Like
@ricklinux @pebcak thankyou for your replies - the delay has randomly stopped happening… maybe it’s hardware related. If it happens again I’ll be back here with more info, including the log that @pebcak requested. @ricklinux I ran that command and got `Failed to connect to bus: No medium found’
Probably didn’t need to use sudo?
Example:
[ricklinux@asus-tuff ~]$ systemctl --user list-jobs
No jobs running.