You are not logged in.
Pages: 1
Hi! A few days ago I started having a weird issue when my OS boots up fine (Debian testing) but after logging in through LightDM, the screen freezes (I can move the pointer) and takes about 2 minutes to show my desktop. After that everything works great.
I tried clearing out the session cache (rm -rf .cache/sessions/*) and that didn't change anything. I tried disabling startup scripts in XFCE and all crontabs and that didn't fix it either. After that I tried creating a new user and login as root as well through another TTY and the issue still persists. Any idea on what I could look into next?
Offline
I forgot to add my .xsession-errors, whenever I log in it hangs with these lines
Xsession: X session started for root at Sun 15 Aug 2021 01:40:46 PM -03
WARNING: tempfile is deprecated; consider using mktemp instead.
dbus-update-activation-environment: setting DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/0/bus
dbus-update-activation-environment: setting DISPLAY=:1
dbus-update-activation-environment: setting XAUTHORITY=/root/.Xauthority
localuser:root being added to access control list
dbus-update-activation-environment: setting GTK_MODULES=gail:atk-bridge
dbus-update-activation-environment: setting QT_ACCESSIBILITY=1
and after 2 minutes it keeps login info (just setting variables, nothing useful there)
Offline
dbus-update-activation-environment: setting XAUTHORITY=/root/.Xauthority
Does the same happen if you log in as a normal user and not root?
You also might have some more meaningful in system logs. If using systemd:
journalctl -b 0 --no-pager
...otherwise, syslog or dmesg.
Please remember to mark your thread [SOLVED] to make it easier for others to find
--- How To Ask For Help | FAQ | Developer Wiki | Community | Contribute ---
Offline
i'd be watching for storage drive activity over the course of those 2 minutes. if you log out and log back in (same user) without rebooting, do you still get the same 2 minute delay? what does "I tried creating a new user and login as root" mean? did you login as the new user?
my first general suspicion for a delay would be the X server starting up.
Offline
Login out and in back again with the same user shows the same delay. As for other users I've tried the normal user login, the root user login and even a newly created user and they all show the same behaviour. Maybe I should install another Desktop Environment to verify if the issue is isolated to XFCE?
Regarding the logs, dmesg doesn't show anything strange, and the journalctl command that ToZ posted has A LOT of info so I'm going to try to filter out some lines and get back if I see something strange.
Offline
You could try the package 'haveged', install and reboot.
Also
systemd-analyze blame
Offline
I don't know if this information means anything, but for what it's worth I have always had this problem with vanilla Debian. Even if I try and boot the 10.10 or 11.0 Live CDs I get the exact same problem as you where it hangs for several minutes on a black screen with just the mouse. It's not specific to XFCE either, I've gotten it using the Gnome version too (although interestingly, never the KDE version). It also doesn't seem to happen on other Debian-derived distros; I never saw it on Xubuntu or Mint+XFCE, it's something weird about straight Debian.
Offline
I have always had this problem with vanilla Debian. Even if I try and boot the 10.10 or 11.0 Live CDs I get the exact same problem as you where it hangs for several minutes on a black screen with just the mouse..
Typically a gpu firmware issue, not included in vanilla Debian. Included on most 'buntu's.
Offline
then it's not a reboot issue. it could be a LightDM issue or more likely an Xorg issue such as X trying something it has to wait on. can you do an SSH login to it from another machine (even Windows or Mac) to see if it has the same issue and if not, to see what's happening during those 2 minutes?
Offline
Update: I didn't try to SSH from another machine but I did try to login on TTY7 and go back to TTY1 to watch logs, and nothing on the syslog as well. TTY login works just fine, no delay there. I wanted to test if it was an issue of XFCE so I installed Openbox, and tried to login with a different DE (or WM in Openbox's case) and the delay is still there, so I'm assuming it's not an issue with XFCE. Sorry for creating the post here, I'm thinking it's an issue with Xorg? I tried to do a startx from another TTY and the login delay is still there, so it's probably not a LightDM issue either. I'm out of ideas.
Last edited by oliveeartquakesong (2021-08-19 23:21:11)
Offline
You could try the package 'haveged', install and reboot.
Alsosystemd-analyze blame
Greetings! Did you try running the above utility? I found it very helpful in the past with both networking- and disk-drive problems/issues. Perhaps you could also run the following command ...
inxi -Fxzi
and post the result? That might give us some insight into how your system is configured, and if there any driver issues we could point to that might explain what's causing those boot-delays.
Cheers, m4a
Linux Mint 21.2 -- xfce 4.18 ... Apple iMAC -- Dell & HP Desktops and Laptops -- Family & Community Support
Offline
Thanks for the reply! Here's the output of systemd-analyze blame. I don't think it's an issue with anything systemd related since the login screen shows up fairly quickly. And the times printed don't get even close to a 2 min delay.
1.928s NetworkManager-wait-online.service
1.539s snap-chromium-1691.mount
1.527s snap-clementine-1361.mount
1.520s snap-gnome\x2d3\x2d28\x2d1804-161.mount
1.379s snap-gtk\x2dcommon\x2dthemes-1515.mount
1.354s snap-kde\x2dframeworks\x2d5\x2dcore18-32.mount
1.292s snap-core18-2128.mount
1.238s snapd.service
1.220s snap-core20-1026.mount
1.143s snap-core-11420.mount
1.069s snap-core20-1081.mount
1.069s snap-gnome\x2d3\x2d28\x2d1804-145.mount
985ms snap-gtk\x2dcommon\x2dthemes-1514.mount
905ms snap-spot-68.mount
846ms snap-atom-282.mount
840ms snap-core-11316.mount
781ms snap-clementine-1371.mount
719ms dev-mapper-winxp\x2d\x2dvg\x2droot.device
705ms dev-loop4.device
687ms snap-gnome\x2d3\x2d38\x2d2004-39.mount
675ms snap-chromium-1708.mount
669ms blueman-mechanism.service
665ms dev-loop3.device
661ms snap-gnome\x2d3\x2d38\x2d2004-70.mount
656ms snap-spotify-46.mount
634ms upower.service
628ms vboxdrv.service
593ms dev-loop5.device
581ms dev-loop2.device
573ms apt-daily.service
568ms snap-atom-281.mount
557ms snap-core18-2074.mount
556ms dev-loop7.device
542ms snapd.seeded.service
501ms apt-daily-upgrade.service
494ms man-db.service
474ms postfix@-.service
444ms dev-loop8.device
442ms dev-loop9.device
409ms containerd.service
As for the output of inxi, I don't think it's anything hardware related, I've had this computer with the same configuration for about 2 years and this never happened before, and I didn't change any of the hardware. Maybe there was a log I forgot to check. I'll try to take a look at Xorg over the weekend.
Offline
Thank you for running the "systemd-analyze blame" command. It provides some useful insights, after all. The per-process timings listed show only cpu-/core-time spent, but NOT the actual elapsed time.
So I started looking, and as far as i can see, you are loading 21 snap packages, where each container is (a) being mounted as a virtual drive, (b) decompressed, and (c) validated over the network against that respective container's current version on ubuntu's snap store. All that takes elapsed time, and I have no idea if your system's "snap service" is using multi-dispatch (parallel processing) or single-threads some of the containers.
Because some components, i.e. gtk, are pre-requisites for xfce, your post-login session will have to wait until all those dependencies are up and running ... So, imho, that's where your elapsed time goes. You can simply test my theory: burn Mint's xfce-spin, now @ v20.2, onto a usb drive and take it for a drive. It should be peppy and snappy, but it runs without those snaps.
Cheers, m4a
Linux Mint 21.2 -- xfce 4.18 ... Apple iMAC -- Dell & HP Desktops and Laptops -- Family & Community Support
Offline
Hey! thanks for the advice. I haven't had time to test the live usb. I did however purge almost all snap packages that I wasn't using, leaving only snap-core and snap-chromium and the time remained the same. I don't believe this is the issue because I didn't change any services installed recently, and the issue only started happening about a week ago. This is the new "systemd-analyze blame"
8.569s logrotate.service
2.998s NetworkManager-wait-online.service
1.408s snapd.service
731ms dev-mapper-winxp\x2d\x2dvg\x2droot.device
697ms blueman-mechanism.service
693ms systemd-rfkill.service
673ms upower.service
624ms snap-chromium-1708.mount
623ms snap-core-11316.mount
616ms snap-core18-2128.mount
570ms vboxdrv.service
542ms snapd.seeded.service
541ms dev-loop3.device
530ms snap-core-11420.mount
526ms snap-core20-1026.mount
497ms dev-loop5.device
493ms snap-chromium-1691.mount
489ms dev-loop4.device
489ms snap-core18-2074.mount
485ms snap-core20-1081.mount
477ms apt-daily.service
471ms containerd.service
462ms dev-loop8.device
457ms apt-daily-upgrade.service
431ms snap-spotify-46.mount
429ms postfix@-.service
423ms vmware-USBArbitrator.service
393ms dev-loop6.device
385ms dev-loop7.device
337ms dev-loop0.device
329ms libvirtd.service
326ms man-db.service
315ms netfilter-persistent.service
293ms udisks2.service
286ms dev-loop2.device
Offline
... This is the new "systemd-analyze blame" ...
<snip>
2.998s NetworkManager-wait-online.service
<snip>
With all due respect, i see that your systemd timings are incomplete, i.e. there's no timing for the logind.service etc. But that's ok with me -- no need to show all. The foregoing timing, ime, seems to be the culprit for your login-delay. As you can glean @ https://askubuntu.com/questions/1018576 … service-do and @ https://access.redhat.com/documentation … networking your "user-session" (read: post-login) appears to either (a) not reach the desired network target, or (b) is encountering a racing condition with a contending service, or (c) encounters network contention/misconfiguration that runs up against the -wait-online.service's timeout setting(s).
Very difficult to drill into, or track down. Many years ago, I fixed thouse problems by using a network analyzer on an offline network to track down the "wanted" network target, then backtracked to the servcie or app requesting it and tweaked its settings accordingly. But in today's world ... you still have a lot of stuff starting up, snaps and all, including your development goodies, so you have a much better idea of what network target must be reached before your desktop is fully configured. Perhaps a cloud-based font lib, or icon set, that can't be found?
Cheers, m4a
Linux Mint 21.2 -- xfce 4.18 ... Apple iMAC -- Dell & HP Desktops and Laptops -- Family & Community Support
Offline
Sorry about the delay in replying, and thank you for the detailed response. No problem about the observation @mint4all, it was a valid concern. I posted the last lines because I thought they were the most relevant ones but here's the full output. I tried disabling the NetworkManager-wait-online.service which apparently was taking a long time, and was the main one that the posts you recommended were talking about, but unfortunately it didn't make a difference. I'll try to keep researching and update the thread if something new comes up. Here's the full output of the systemd-analyze blame like you asked.
1.244s snapd.service
741ms postfix@-.service
708ms snap-chromium-1691.mount
707ms snap-core-11606.mount
699ms snap-core20-1081.mount
670ms blueman-mechanism.service
657ms snap-core18-2128.mount
656ms snap-core20-1026.mount
640ms upower.service
635ms dev-mapper-myhostname\x2d\x2dvg\x2droot.device
588ms apt-daily-upgrade.service
561ms snapd.seeded.service
555ms snap-chromium-1708.mount
554ms snap-core-11420.mount
551ms snap-core18-2074.mount
547ms snap-spotify-46.mount
484ms vboxdrv.service
474ms apt-daily.service
468ms containerd.service
422ms netfilter-persistent.service
411ms man-db.service
359ms vmware-USBArbitrator.service
358ms dev-loop3.device
354ms libvirtd.service
350ms dev-loop2.device
301ms dev-loop5.device
301ms dev-loop4.device
284ms udisks2.service
275ms dev-loop1.device
274ms dev-loop0.device
259ms dev-loop8.device
259ms systemd-rfkill.service
252ms ModemManager.service
227ms accounts-daemon.service
217ms dev-loop7.device
204ms systemd-timesyncd.service
204ms dev-loop6.device
190ms apparmor.service
176ms user@1000.service
166ms boot-efi.mount
145ms bluetooth.service
135ms systemd-journal-flush.service
130ms polkit.service
125ms colord.service
124ms dundee.service
121ms ofono.service
119ms logrotate.service
116ms lightdm.service
107ms systemd-logind.service
101ms systemd-machined.service
94ms wpa_supplicant.service
92ms systemd-udev-trigger.service
91ms lvm2-pvscan@253:0.service
89ms NetworkManager.service
86ms lvm2-monitor.service
85ms mono-xsp4.service
83ms networking.service
80ms plymouth-quit-wait.service
78ms systemd-udevd.service
78ms systemd-journald.service
70ms alsa-restore.service
61ms systemd-backlight@leds:dell::kbd_backlight.service
60ms lm-sensors.service
56ms fancontrol.service
42ms systemd-tmpfiles-clean.service
42ms systemd-fsck@dev-disk-by\x2duuid-cx098bf8\x2d7f10\x2d4cff\x2db358\x2d9efdc4e9b666.service
41ms dev-mapper-myhostname\x2d\x2dvg\x2dswap_1.swap
39ms e2scrub_reap.service
39ms systemd-fsck@dev-disk-by\x2duuid-562E\x2dDB19.service
37ms run-rpc_pipefs.mount
30ms hddtemp.service
30ms systemd-modules-load.service
29ms rsyslog.service
27ms systemd-tmpfiles-setup.service
22ms binfmt-support.service
18ms plymouth-start.service
16ms systemd-user-sessions.service
16ms cups.service
15ms systemd-cryptsetup@sda3_crypt.service
14ms rpcbind.service
14ms libvirt-guests.service
14ms dev-hugepages.mount
13ms dev-mqueue.mount
13ms avahi-daemon.service
12ms sys-kernel-debug.mount
12ms user-runtime-dir@1000.service
12ms systemd-sysusers.service
12ms sys-kernel-tracing.mount
12ms plymouth-read-write.service
12ms modprobe@fuse.service
11ms systemd-update-utmp.service
11ms keyboard-setup.service
11ms systemd-tmpfiles-setup-dev.service
11ms kmod-static-nodes.service
11ms openvpn.service
10ms modprobe@configfs.service
10ms modprobe@drm.service
8ms systemd-sysctl.service
8ms systemd-random-seed.service
8ms systemd-remount-fs.service
8ms apt-listbugs.service
8ms docker.socket
7ms systemd-backlight@backlight:intel_backlight.service
6ms boot.mount
5ms proc-sys-fs-binfmt_misc.mount
5ms systemd-update-utmp-runlevel.service
5ms console-setup.service
5ms nfs-config.service
4ms snapd.socket
3ms sys-kernel-config.mount
3ms rtkit-daemon.service
3ms ifupdown-pre.service
2ms sys-fs-fuse-connections.mount
2ms e2scrub_all.service
1ms postfix.service
23us blk-availability.service
Offline
After a couple of months, I realized that this issue only happens whenever the computer boots with an external monitor attached, it doesn't happen when using the only the notebook. So it's probably not service related. Just wanted to leave it here in case anybody else experiences the same issue.
Offline
Pages: 1