Hello,
I noticed that the KDE environment of both SLED 12 SP3 and openSUSE 42.3 always stack without any reasons at any time. The login time is also much slower than GNOME or MATE enviornment. Could the developer pay attention to these issues for the coming SLED 15?
Thank you very much.
[QUOTE=albumns;51059]Hello,
I noticed that the KDE environment of both SLED 12 SP3 and openSUSE 42.3 always stack without any reasons at any time. The login time is also much slower than GNOME or MATE enviornment. Could the developer pay attention to these issues for the coming SLED 15?
Thank you very much.[/QUOTE]
Hi
Since KDE arrives via SUSE Package Hub, then would suggest looking at openSUSE Leap 15 (in testing now) and resolve there, then it will channel through to SUSE Package Hub…
Have you run ‘systemd-analyze blame’ and ‘systemd-analyze critical-chain’ to see what may be slowing things down?
here is the output for " systemd-analyze blame"
731ms dkms.service
586ms display-manager.service
529ms SuSEfirewall2.service
392ms dev-sdb1.device
374ms NetworkManager-wait-online.service
350ms vboxdrv.service
268ms systemd-rfkill.service
256ms postfix.service
200ms upower.service
176ms systemd-fsck@dev-disk-by\\x2duuid-dc699829\\x2d07c0\\x2d41a6\\x2d9c32\\x2d1ee5dfb0e274.service
154ms SuSEfirewall2_init.service
140ms logrotate.service
135ms ModemManager.service
74ms rsyslog.service
73ms udisks2.service
65ms systemd-backlight@backlight:intel_backlight.service
61ms polkit.service
61ms lm_sensors.service
54ms alsa-restore.service
53ms rc-local.service
51ms btrfsmaintenance-refresh.service
50ms nscd.service
48ms systemd-udevd.service
41ms systemd-udev-trigger.service
36ms NetworkManager.service
35ms ntpd.service
28ms user@1000.service
27ms wpa_supplicant.service
20ms systemd-backlight@leds:dell::kbd_backlight.service
16ms systemd-journald.service
16ms systemd-remount-fs.service
16ms avahi-daemon.service
15ms boot-efi.mount
14ms systemd-logind.service
14ms colord.service
13ms plymouth-read-write.service
13ms plymouth-start.service
11ms systemd-tmpfiles-clean.service
11ms systemd-modules-load.service
11ms home.mount
10ms accounts-daemon.service
10ms systemd-tmpfiles-setup-dev.service
10ms kmod-static-nodes.service
9ms systemd-fsck-root.service
9ms systemd-vconsole-setup.service
8ms systemd-sysctl.service
8ms bluetooth.service
8ms dev-mqueue.mount
7ms geoclue.service
7ms systemd-journal-flush.service
7ms systemd-tmpfiles-setup.service
7ms sys-kernel-debug.mount
6ms dev-hugepages.mount
6ms dev-disk-by\\x2duuid-eac8e590\\x2d7496\\x2d461b\\x2daa35\\x2d926b190eec9d.swap
6ms mcelog.service
5ms systemd-udev-root-symlink.service
4ms systemd-user-sessions.service
4ms vboxballoonctrl-service.service
4ms vboxweb-service.service
4ms vboxautostart-service.service
4ms systemd-random-seed.service
3ms systemd-update-utmp.service
3ms rtkit-daemon.service
2ms sys-fs-fuse-connections.mount
2ms systemd-update-utmp-runlevel.service
1ms dracut-shutdown.serviceAnd here is the output for " systemd-analyze critical-chain"
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.
graphical.target @2.493s
└─display-manager.service @1.905s +586ms
└─dkms.service @1.173s +731ms
└─basic.target @1.166s
└─sockets.target @1.166s
└─pcscd.socket @1.166s
└─sysinit.target @1.166s
└─systemd-update-utmp.service @1.161s +3ms
└─systemd-tmpfiles-setup.service @1.153s +7ms
└─local-fs.target @1.151s
└─boot-efi.mount @1.135s +15ms
└─dev-disk-by\\x2duuid-8EB6\\x2d7142.device @1.095s