Manjaro KDE and Cinnamon auto login delay

—Hi,
My first post here and first time I’ve tried various flavours of Manjaro.
In general I’m impressed, but the very latest update causes a long delay in getting the desktop loaded with auto login selected, as demonstrated in the lightdm.log below:

cat /var/log/lightdm/lightdm.log
[+0.00s] DEBUG: Logging to /var/log/lightdm/lightdm.log
[+0.00s] DEBUG: Starting Light Display Manager 1.28.0, UID=0 PID=365
[+0.00s] DEBUG: Loading configuration dirs from /usr/share/lightdm/lightdm.conf.d
[+0.00s] DEBUG: Loading configuration dirs from /usr/local/share/lightdm/lightdm.conf.d
[+0.00s] DEBUG: Loading configuration dirs from /etc/xdg/lightdm/lightdm.conf.d
[+0.00s] DEBUG: Loading configuration from /etc/lightdm/lightdm.conf
[+0.00s] DEBUG: [VNCServer] contains unknown option user-session
[+0.00s] DEBUG: [VNCServer] contains unknown option session-wrapper
[+0.00s] DEBUG: [VNCServer] contains unknown option autologin-user
[+0.00s] DEBUG: Registered seat module local
[+0.00s] DEBUG: Registered seat module xremote
[+0.00s] DEBUG: Registered seat module unity
[+0.00s] DEBUG: Using D-Bus name org.freedesktop.DisplayManager
[+0.02s] DEBUG: Monitoring logind for seats
[+0.02s] DEBUG: New seat added from logind: seat0
[+0.02s] DEBUG: Seat seat0: Loading properties from config section Seat:*
[+0.02s] DEBUG: Seat seat0: Starting
[+0.02s] DEBUG: Seat seat0: Creating user session
[+0.12s] DEBUG: Loading users from org.freedesktop.Accounts
[+0.12s] DEBUG: User /org/freedesktop/Accounts/User1000 added
[+0.19s] DEBUG: Seat seat0: Creating display server of type x
[+0.19s] DEBUG: posix_spawn avoided (fd close requested)
[+0.19s] DEBUG: Could not run plymouth --ping: Failed to execute child process “plymouth” (No such file or directory)
[+0.19s] DEBUG: Using VT 7
[+0.19s] DEBUG: Seat seat0: Starting local X display on VT 7
[+0.19s] DEBUG: XServer 0: Logging to /var/log/lightdm/x-0.log
[+0.19s] DEBUG: XServer 0: Writing X server authority to /run/lightdm/root/:0
[+0.19s] DEBUG: XServer 0: Launching X Server
[+0.19s] DEBUG: Launching process 456: /usr/bin/X :0 -seat seat0 -auth /run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
[+0.19s] DEBUG: XServer 0: Waiting for ready signal from X server :0
[+0.19s] DEBUG: Acquired bus name org.freedesktop.DisplayManager
[+0.19s] DEBUG: Registering seat with bus path /org/freedesktop/DisplayManager/Seat0
[+0.19s] DEBUG: posix_spawn avoided (automatic reaping requested) (fd close requested)
[+0.80s] DEBUG: Got signal 10 from process 456
[+0.80s] DEBUG: XServer 0: Got signal from X server :0
[+0.80s] DEBUG: XServer 0: Connecting to XServer :0
[+0.90s] DEBUG: posix_spawn avoided (fd close requested) (child_setup specified)
[+0.90s] DEBUG: Seat seat0: Display server ready, starting session authentication
[+0.90s] DEBUG: Session pid=596: Started with service ‘lightdm-autologin’, username ‘david’
[+0.92s] DEBUG: Session pid=596: Authentication complete with return value 0: Success
[+0.92s] DEBUG: Seat seat0: Session authenticated, running command
[+0.92s] DEBUG: Registering session with bus path /org/freedesktop/DisplayManager/Session0
[+0.92s] DEBUG: posix_spawn avoided (fd close requested) (child_setup specified)
[+0.92s] DEBUG: Session pid=596: Running command /etc/lightdm/Xsession cinnamon-session-cinnamon
[+0.92s] DEBUG: Creating shared data directory /var/lib/lightdm-data/david
[+0.92s] DEBUG: Session pid=596: Logging to .xsession-errors
[+128.55s] DEBUG: Activating VT 7
[+128.55s] DEBUG: Activating login1 session 1
[+128.55s] DEBUG: Seat seat0 changes active session to 1
[+128.55s] DEBUG: Session 1 is already active

When manual login is selected, i.e username and password supplied, there is no extended delay.

The issue is not there in the 18.0 iso’s, but as soon as updates are applied the problem occurs.

I am running Manjaro (and several other flavours of Linux) in Vmware Player version 15. No delays are present with other distro’s.

Any help appreciated!

Thank you.

No visible error in the log AFAIK (DEBUG is not an error)
To search for potential delays run

systemd-analyze blame
journalctl -b -p3

You may post them, if you want an advice, as well as

inxi -Fxxxz

but, please, use proper formatting for the output text

4 Likes

Apologies if formatting not to standard - Will try harder :grinning:

The /var/log/lightdm/lightdm.log file shows the issue - the difference in time between the times on the debug error messages between the fourth and fifth message from the bottom - over two minutes in this case.

Funnily enough I had already looked at the log from systemd-analyze blame, but it didn’t show anything unusual - a few seconds in total. Yes, I know it is ‘odd’ that booting takes over 2 minutes when this log doesn’t show an issue.

I will look at the other log later when I have access to the Manjaro machine.

A couple of services run once in a while to refresh databases, like mandb. It’s usual. If after several boots or days, you still have long boot time, then check again. The only way I know is systemd-analyze. Check man page or post output.

Ok, more info as requested.

Firstly on the system from inxi:

System:    Host: Manjaro Kernel: 4.19.6-1-MANJARO x86_64 bits: 64 compiler: gcc v: 8.2.1 
           Desktop: Cinnamon 4.0.3 dm: LightDM 1.28.0 Distro: Manjaro Linux 
Machine:   Type: Vmware System: VMware product: VMware Virtual Platform v: N/A serial: <filter> 
           Chassis: No Enclosure type: 1 serial: <filter> 
           Mobo: Intel model: 440BX Desktop Reference Platform serial: <filter> BIOS: Phoenix v: 6.00 
           date: 04/13/2018 
CPU:       Topology: 4x Single Core model: Intel Core i5-2500K bits: 64 type: SMP arch: Sandy Bridge rev: 7 
           L2 cache: 24.0 MiB 
           flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 bogomips: 26408 
           Speed: 3300 MHz min/max: N/A Core speeds (MHz): 1: 3300 2: 3300 3: 3300 4: 3300 
Graphics:  Device-1: VMware SVGA II Adapter driver: vmwgfx v: 2.15.0.0 bus ID: 00:0f.0 chip ID: 15ad:0405 
           Display: x11 server: X.Org 1.20.3 driver: vmware tty: N/A 
           OpenGL: renderer: SVGA3D; build v: 3.3 Mesa 18.2.6 compat-v: 3.1 direct render: Yes 
Audio:     Device-1: Ensoniq ES1371/ES1373 / Creative Labs CT2518 driver: snd_ens1371 v: kernel 
           bus ID: 02:02.0 chip ID: 1274:1371 
           Sound Server: ALSA v: k4.19.6-1-MANJARO 
Network:   Device-1: Intel 82371AB/EB/MB PIIX4 ACPI vendor: VMware Virtual Machine type: network bridge 
           driver: N/A port: 1060 bus ID: 00:07.3 chip ID: 8086:7113 
           Device-2: Intel 82545EM Gigabit Ethernet vendor: VMware PRO/1000 MT Single Port driver: e1000 
           v: 7.3.21-k8-NAPI port: 2000 bus ID: 02:01.0 chip ID: 8086:100f 
           IF: ens33 state: up speed: 1000 Mbps duplex: full mac: <filter> 
Drives:    Local Storage: total: 20.00 GiB used: 6.53 GiB (32.7%) 
           ID-1: /dev/sda vendor: VMware model: Virtual S size: 20.00 GiB serial: N/A rev: 1.0 scheme: MBR 
Partition: ID-1: / size: 15.45 GiB used: 6.53 GiB (42.3%) fs: ext4 dev: /dev/sda1 
           ID-2: swap-1 size: 4.23 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/sda2 
Sensors:   Message: No sensors data was found. Is sensors configured? 
Info:      Processes: 218 Uptime: 3m Memory: 3.83 GiB used: 900.7 MiB (23.0%) Init: systemd v: 239 Compilers: 
           gcc: 8.2.1 Shell: bash v: 4.4.23 running in: gnome-terminal inxi: 3.0.27 
1 Like

And systemd-analyze blame:

systemd-analyze blame
           733ms dev-sda1.device
           588ms tlp.service
           343ms systemd-sysusers.service
           294ms ModemManager.service
           245ms upower.service
           212ms systemd-journal-flush.service
           206ms udisks2.service
           201ms lightdm.service
           181ms polkit.service
           166ms ldconfig.service
           158ms systemd-udev-trigger.service
           115ms NetworkManager.service
            95ms systemd-journal-catalog-update.service
            90ms systemd-journald.service
            76ms lvm2-monitor.service
            73ms add-autologin-group.service
            72ms avahi-daemon.service
            67ms accounts-daemon.service
            67ms systemd-logind.service
            40ms user@1000.service
            40ms grub-boot-indeterminate.service
            35ms systemd-tmpfiles-setup.service
            33ms systemd-udevd.service

As you can see, nothing here that accounts for several minutes delay.

As per my first post, no such delay with the 1.8.0 iso or if you enter a username and password with the updated version.

Is there an other Manjaro forum that could help or is it a case of installing Arch and trying that? Antergos doesn’t exhibit the problem though which is also based on Arch.

Must have booted 30+ times over 3 days and a similar delay every time.

1 Like

Ok, as an experiment I have just downloaded the Xcfe version and setup a VM with that.

With the base 18.0-stable version the desktop appears in under 15 seconds. I tried 5 times.

I then applied the 325 updates identified and now it takes over 2 minutes for the desktop to appear. Again, I’ve tried 5 times. So the issue also applies to the Xfce version.

If it is any help the delay seems to appear after when the user/password screen would appear if autologin wasn’t set.

So it looks to me as if there is a bug in one of the 235 packages that is loaded as an update, but which one?

1 Like

@AgentS : Would a change of lightdm to sddm be useful for tracing the culprit down?

I have no experience in VMware, which is a proprietary software.
Whether sddm or lightdm, if there is no evidence in the logs, I can’t see how one could find the problem.

My advice is subjective: Prioritize your needs.
If fast booting is a big problem, try to install those 325 updates one at a time, to find which one brings the delay.
If not, use your system (which works fine after boot) until you are comfortable enough to install on real hardware.
Or do whatever is your real goal, maybe you want to learn Linux, by hunting down a bug.

I wouldn’t spent my time on troubleshooting a proprietary, pseudo-PC (Virtual machine).

Nevertheless, there maybe a placebo effect with silent grub in conjunction with autologin and possibly a package regression which may happen in rare circumstances.

I sincerely wish the problem will be found.

1 Like

Could be that your Lightdm has the same issue as above? It’s not a solution, but maybe you’re not alone (and switching to sddm might be worth a try …)

To answer some of the questions, I should first give a little background. I have worked in and run UNIX server development groups for many years and also used VMware commercially and at home to enable rapid of switching of environments for developers and testers. It is a solid product.

My use of Linux is very much a hobby, but I find it far better than Windows for certain tasks. Hence my use of Linux VM’s. I also have various old machines running
flavours of Linux that work well for old 32-bit processors, e.g. MX Linux, Mint.

For many years I have been running OpenSuse Tumbleweed as my main Linux environment, but am always trying other distro’s. The Arch distro has some appeal due to its speed, but I just don’t have the enthusiasm to setup from scratch. I have Antergos in a VM but that is too fragile to trust for real work. Manjaro had some good reviews recently so thought I’d give that a go.

I’m also a bit of a perfectionist so I like distro’s that are solid, so when a new one is installed I look for obvious issues and this is the first I’ve found with Manjaro. Not a big issue, but makes me wonder how many other issues are present (Just found that after building puddletag from AUR it doesn’t load. Might be a QT4/5 incompatibility issue, investigating).

I won’t be installing the update packages individually, but I will do some more investigation. I haven’t tried the Gnome version yet either!

Comparing apples to oranges IMO. If it didn’t happen on bare metal, it didn’t happen. Virtual irrelevance.

You 'd be surprised if you had tried. Print the installation guide and you are gone!.. Some users do this blind, in 10 min. And…

perfectionist + investigating = Archlinux user

Perfect match IMHO.

@tbg this is BA!! :smile::rofl:

1 Like

Try sddm as others suggested as this seems to replicate issues with lightdm/auto login in debian.

Ok, tried the Gnome version this evening and the same issue is present. This version also uses gdm I believe which means lightdm is not the issue?

To rule out factors, I would suggest disabling silent boot, following the instructions about it.
Please don’t ask me where to find them. I really don’t know, I have to search too, so maybe you find them sooner… :wink:

Yes, I tried enabling console messages during boot but the same messages are produced in the auto login and manual login cases - no errors. I also took a copy of the more detailed messages produced by dmesg, the section of which shows the delay issue is below:

[    2.403972] checking generic (e8000000 130000) vs hw (e8000000 400000)
[    2.403974] fb: switching to svgadrmfb from VESA VGA
[    2.404110] fbcon: svgadrmfb (fb0) is primary device
[    2.404111] fbcon: Deferring console take-over
[    2.404832] [drm] Initialized vmwgfx 2.15.0 20180704 for 0000:00:0f.0 on minor 0
[    2.821190] e1000 0000:02:01.0 eth0: (PCI:66MHz:32-bit) 00:0c:29:12:a5:a4
[    2.821196] e1000 0000:02:01.0 eth0: Intel(R) PRO/1000 Network Connection
[    2.828544] e1000 0000:02:01.0 ens33: renamed from eth0
[    2.848494] IPv6: ADDRCONF(NETDEV_UP): ens33: link is not ready
[    2.853001] IPv6: ADDRCONF(NETDEV_UP): ens33: link is not ready
[    2.857111] e1000: ens33 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
[    2.857896] IPv6: ADDRCONF(NETDEV_CHANGE): ens33: link becomes ready
[   13.014233] kauditd_printk_skb: 25 callbacks suppressed
[   13.014234] audit: type=1131 audit(1544801073.668:36): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=NetworkManager-dispatcher comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[   32.641348] audit: type=1131 audit(1544801093.295:37): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-hostnamed comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[  152.081033] random: crng init done
[  152.081036] random: 7 urandom warning(s) missed due to ratelimiting
[  152.189075] fuse init (API version 7.27)
[  152.719012] audit: type=1130 audit(1544801213.371:38): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=rtkit-daemon comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[  152.932342] audit: type=1130 audit(1544801213.588:39): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=org.cups.cupsd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[  152.969742] audit: type=1130 audit(1544801213.625:40): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=colord comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[  153.131727] audit: type=1130 audit(1544801213.785:41): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=upower comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[  153.298068] audit: type=1130 audit(1544801213.951:42): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=udisks2 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[  155.047893] audit: type=1130 audit(1544801215.701:43): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=pamac-system comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[  155.067284] audit: type=1131 audit(1544801215.721:44): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=pamac-system comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

As you can see, things go quiet between 32 and 152 seconds until crng init done.

I’ve also installed on a second machine running the earlier version 12 of VMware (older hardware). Exactly the same result - 18.0 desktop come up immediately, but plus updates there is a delay.

Also, by accident, I found that by either clicking the mouse or pressing enter during the delay period causes the wait to end after a few seconds.

It is as if some part of the auto login process is waiting for input even though the screen is blank.

Looking online seems I’m not the only one to have experienced the wait for crng init done. https://unix.stackexchange.com/questions/442698/when-i-log-in-it-hangs-until-crng-init-done

This was a Debian issue, now fixed. Maybe the same issue in the the latest Arch updates?

Now going to try previous Kernels…

Seems fine with Kernel 4.18.20-1. Issue is with Kernel 4.19.6-1.

Here is the same section of the dmsg log:

[    2.548634] checking generic (e8000000 130000) vs hw (e8000000 400000)
[    2.548636] fb: switching to svgadrmfb from VESA VGA
[    2.548650] Console: switching to colour dummy device 80x25
[    2.549905] fbcon: svgadrmfb (fb0) is primary device
[    2.552787] Console: switching to colour frame buffer device 100x37
[    2.568515] [drm] Initialized vmwgfx 2.14.1 20180322 for 0000:00:0f.0 on minor 0
[    2.644050] NET: Registered protocol family 40
[    2.796550] e1000 0000:02:01.0 eth0: (PCI:66MHz:32-bit) 00:0c:29:12:a5:a4
[    2.796555] e1000 0000:02:01.0 eth0: Intel(R) PRO/1000 Network Connection
[    2.805564] e1000 0000:02:01.0 ens33: renamed from eth0
[    3.241409] IPv6: ADDRCONF(NETDEV_UP): ens33: link is not ready
[    3.245815] IPv6: ADDRCONF(NETDEV_UP): ens33: link is not ready
[    3.246749] e1000: ens33 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
[    3.247575] IPv6: ADDRCONF(NETDEV_CHANGE): ens33: link becomes ready
[    9.437855] random: crng init done
[    9.437869] random: 7 urandom warning(s) missed due to ratelimiting
[    9.625703] fuse init (API version 7.27)
[   10.243913] kauditd_printk_skb: 23 callbacks suppressed
[   10.243914] audit: type=1130 audit(1544804869.074:34): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=rtkit-daemon comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[   10.453952] audit: type=1130 audit(1544804869.284:35): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=colord comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[   10.480376] audit: type=1130 audit(1544804869.310:36): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=upower comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[   10.519060] audit: type=1130 audit(1544804869.347:37): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=org.cups.cupsd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[   10.672827] audit: type=1130 audit(1544804869.500:38): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=udisks2 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[   12.516789] audit: type=1130 audit(1544804871.344:39): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=pamac-system comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[   12.524497] audit: type=1131 audit(1544804871.354:40): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=pamac-system comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[   13.012147] audit: type=1131 audit(1544804871.840:41): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=NetworkManager-dispatcher comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

Do you guys have access to the Kernel dev team and/or can add a Kernel flag?

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.

Forum kindly sponsored by