| Summary: | When utilizing the Breeze theme for SDDM, it takes ages for SDDM to startup. | ||
|---|---|---|---|
| Product: | [Plasma] Breeze | Reporter: | Raymond Wooninck <tittiatcoke> |
| Component: | general | Assignee: | Plasma Development Mailing List <plasma-devel> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | blaze, ellisistfroh, filipfila.kde, hrvoje.senjan, kamikazow, kde, kde, lbeltrame, marco.napetti, nate, raul.malea, rdieter, rikmills |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: |
journalctl -b output with Breeze theme active for SDDM
journalctl -b output with Maldives theme active for SDDM |
||
|
Description
Raymond Wooninck
2014-12-10 21:26:25 UTC
wow. That's pretty extreme A delay that big must be a DBus timeout (or rather 3 sequential DBus timeouts). We end up querying solid for battery status which does go via an activated kded; so potentially that's where we block. Can you: - confirm what version you are using. - tell me where you get your RPMs from - check the log files from SDDM (journalctl -u sddm) Created attachment 89915 [details]
journalctl -b output with Breeze theme active for SDDM
Created attachment 89916 [details]
journalctl -b output with Maldives theme active for SDDM
Hi David,
The SDDM version that I am using is from git master and we are building it on openSUSE Build Service. I am part of the openSUSE KDE Community team and we are currently testing SDDM to see if we could make the same switch as Fedora from KDM to SDDM. I am using it in connection with a Frameworks/Plasma-next desktop.
SDDM on openSUSE is started through the generic display-manager service. There are indications that we should switch to using separate services for each display-manager, but this has not yet done, so you might see display-manager in the journal logs.
Running systemd-analyze blame delivers (top x lines) the following output:
1min 30.078s display-manager.service
560ms ModemManager.service
536ms systemd-tmpfiles-setup.service
500ms systemd-logind.service
499ms firewalld.service
447ms postfix.service
429ms plymouth-read-write.service
214ms mnt-windows.mount
159ms NetworkManager.service
67ms lvm2-activation-net.service
58ms systemd-fsck@dev-disk-by\x2duuid-a15e9da3\x2d0009\x2d4847\x2d978d\x2d34b3de059089.service
42ms alsa-restore.service
40ms avahi-daemon.service
So I am not sure if the 1min 30secs is really the time required by SDDM or that it just indicates that a total boot time of 1 min is reached and that 30 secs is used for the display-manager.
I have attached two journals (one with the maldives theme active and the other with the breeze theme). These are the full startup journals of the current session. I didn't filter them to prevent loosing information.
I reverted the PowerDevil patch. Please try again with recent PowerDevil. Thanks! Hi Kai, I hope your didn't revert your patch because of this bug report. I am running the latest version from git, but still the same issue. So the revert didn't bring any relief in the startup time of SDDM @ Raymond Starting with Plasma 5.5.4 you can select not to have a start screen (with progress-bar) at all System-Settings -> Desktop-Appearance -> Start-Screen (select) Does this speed up your boot? <OT >There's nothing yet from kde-look.org <OT> Can confirm this for Plasma 5.7.x (K)Ubuntu 16.10 YY. I think that problem here is more global than just sddm plugin. Slow init can reproduced for a quite big number of Qt5 apps. Maybe linking against libicu causes this issue or opensource graphics drivers. Not sure. Needs further investigation. Actually I haven't seen this for quite some time. Also with the changes that Plasma 5.8 will bring to the SDDM theme, the issue no longer occurs with me. Maybe it was fixed with Qt5.7. I have Qt5.6.1. I also cannot replicate this at all: Plasma 5.7.2, and later 5.7.5 Qt 5.6.1 Ubuntu 16.10 (Yakkety) Is this still relevant? Since there have been changes relevant to this bug since it was filed, and folks can no longer reproduce it, let's close it until we get new reports. Thanks everyone! *** Bug 365710 has been marked as a duplicate of this bug. *** |