[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: lightdm (testing): Long waiting time after login



On 16.05.2018 19:51 Dominic Knight wrote:
On Wed, 2018-05-16 at 14:53 +0200, Dino wrote:
Dino wrote:
This is a multi-part message in MIME format.
--------------D295C2A19D414A0F9C32AEE8
Content-Type: multipart/alternative;
   boundary="------------51A034E61483D85CC097E79C"


--------------51A034E61483D85CC097E79C
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

This time with attachment...

Am 16.05.2018 um 09:28 schrieb work@hllmnn.de:
I just did a fresh install of testing with XFCE. After entering
the
login credentials the screen was black for 30-60 seconds before
the
desktop environment showed up. Assuming a bug in XFCE, I
performed
another fresh install with MATE, but a similar effect occured:
after
login the background image is shown for 30-60 seconds before
the
desktop is fully loaded.

A look into /var/log/lightdm/lightdm.log showed that the delay
happens
before VT is activated. The log file is attached.

Might this be a bug in lightdm or could a misconfiguragtion
from my
side cause this issue?
...
[+7.71s] DEBUG: Session pid=691: Running command
/etc/X11/Xsession default
[+7.71s] DEBUG: Creating shared data directory
/var/lib/lightdm/data/USERNAME
[+7.71s] DEBUG: Session pid=691: Logging to .xsession-errors
[+40.89s] DEBUG: Activating VT 7
[+40.89s] DEBUG: Activating login1 session 2
[+40.89s] DEBUG: Seat seat0 changes active session to
[+40.89s] DEBUG: Seat seat0 changes active session to 2
[+40.89s] DEBUG: Session 2 is already active
    what does .xsession-errors say?

    what type of device are you installing to?

    my recent installs with netinst for testing and having MATE
comes up ok (within a few seconds), but things may have changed
in packages.

    does a stable netinst give same results?


    songbird
.xsession-errors contains one warning (file is attached), but I
don't
think that it causes the delay.

The device I'm installing to is an UDOO X86
(https://www.udoo.org/udoo-x86/). Basically, it's standard hardware
with
an Intel CPU. I already had an installation of testing a few months
ago
that didn't show this behaviour.

A stable netinst works just fine, the desktop is loaded almost
immediately. Hence, I assume a package changed recently is the
reason
for this.
Maybe;
systemd-analyze critical-chain
&
systemd-analyze blame
will give a clue as to what is taking its time?

Dom.
The output of systemd-analyze looks fine, I think. It really seems like the bug reported at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897572 is causing the trouble.
          6.228s NetworkManager-wait-online.service
           736ms dev-sda1.device
           585ms networking.service
           470ms NetworkManager.service
           459ms systemd-logind.service
           459ms x2goserver.service
           368ms udisks2.service
           353ms systemd-timesyncd.service
           353ms upower.service
           280ms keyboard-setup.service
           271ms ModemManager.service
           254ms avahi-daemon.service
           189ms lm-sensors.service
           186ms systemd-udev-trigger.service
           171ms speech-dispatcher.service
           162ms wpa_supplicant.service
           146ms lightdm.service
           142ms systemd-journald.service
           129ms user@1000.service
           124ms systemd-tmpfiles-setup.service
           105ms pppd-dns.service
           104ms systemd-update-utmp.service
           101ms user@113.service
           100ms systemd-rfkill.service
            93ms packagekit.service
            91ms rsyslog.service
            76ms systemd-udevd.service
            71ms dev-disk-by\x2duuid-3d5845ff\x2d7dc2\x2d45e6\x2d9495\x2d2a95d09c804c.swap
            69ms ssh.service
            58ms polkit.service
            42ms console-setup.service
            37ms bluetooth.service
            36ms systemd-tmpfiles-clean.service
            34ms systemd-journal-flush.service
            32ms systemd-sysusers.service
            29ms dev-hugepages.mount
            28ms hddtemp.service
            27ms systemd-remount-fs.service
            27ms dev-mqueue.mount
            25ms systemd-tmpfiles-setup-dev.service
            24ms rtkit-daemon.service
            20ms systemd-sysctl.service
            19ms sys-kernel-debug.mount
            18ms systemd-modules-load.service
            18ms systemd-update-utmp-runlevel.service
            17ms kmod-static-nodes.service
            15ms systemd-user-sessions.service
            13ms systemd-random-seed.service

Reply to: