Page 1 of 2 12 LastLast
Results 1 to 10 of 14

Thread: leap 15.2 after upgrade kde taking over 5 minutes to start up from login

  1. #1

    Default leap 15.2 after upgrade kde taking over 5 minutes to start up from login

    After upgrade to 15.2 time to startup from login screen to KDE being ready to respond can be 5 minutes. On 15.1 time was less than 20 secs.

    Suggested commands do not seem to show any KDE startup information that is useful.

    x64Cru_150G:~ # systemd-analyze blame
    8min 40.609s fstrim.service
    8min 22.759s mandb.service
    20.826s backup-rpmdb.service
    7.276s wicked.service
    3.832s user@1001.service
    2.511s systemd-udev-settle.service
    1.251s lvm2-monitor.service
    1.110s display-manager.service
    962ms apparmor.service
    723ms dracut-initqueue.service
    716ms postfix.service
    582ms firewalld.service
    579ms systemd-udevd.service
    549ms ca-certificates.service
    472ms initrd-switch-root.service
    470ms systemd-hwdb-update.service
    249ms polkit.service
    242ms backup-sysconfig.service
    220ms upower.service
    205ms ModemManager.service
    203ms systemd-journal-catalog-update.service

    x64Cru_150G:~ # 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 @13.896s
    └─display-manager.service @12.785s +1.110s
    └─systemd-user-sessions.service @12.743s +37ms
    └─network.target @12.739s
    └─wicked.service @5.461s +7.276s
    └─wickedd-nanny.service @5.420s +39ms
    └─wickedd.service @5.370s +49ms
    └─wickedd-auto4.service @5.316s +52ms
    └─network-pre.target @5.312s
    └─firewalld.service @4.729s +582ms
    └─polkit.service @4.478s +249ms
    └─basic.target @4.409s
    └─sockets.target @4.409s
    └─avahi-daemon.socket @4.408s
    └─sysinit.target @4.398s
    └─sys-fs-fuse-connections.mount @34.439s +3ms
    └─systemd-modules-load.service @255ms +37ms
    └─system.slice

    There is no info that I can detect in the Journal that tells me the reason for the long login. If the cannot be fixed I will have to abandon opensuse. Time is better after system updates, and I reboot that day. However, if system is off for several days then the login time returns to 5 minutes.

    regards,
    Bob

  2. #2
    Join Date
    Jan 2014
    Location
    Erlangen
    Posts
    2,493
    Blog Entries
    1

    Default Re: leap 15.2 after upgrade kde taking over 5 minutes to start up from login

    Quote Originally Posted by bwheater View Post
    After upgrade to 15.2 time to startup from login screen to KDE being ready to respond can be 5 minutes. On 15.1 time was less than 20 secs.

    Suggested commands do not seem to show any KDE startup information that is useful.

    x64Cru_150G:~ # systemd-analyze blame
    8min 40.609s fstrim.service
    8min 22.759s mandb.service
    20.826s backup-rpmdb.service
    7.276s wicked.service
    3.832s user@1001.service
    2.511s systemd-udev-settle.service
    1.251s lvm2-monitor.service
    1.110s display-manager.service
    962ms apparmor.service
    723ms dracut-initqueue.service
    716ms postfix.service
    582ms firewalld.service
    579ms systemd-udevd.service
    549ms ca-certificates.service
    472ms initrd-switch-root.service
    470ms systemd-hwdb-update.service
    249ms polkit.service
    242ms backup-sysconfig.service
    220ms upower.service
    205ms ModemManager.service
    203ms systemd-journal-catalog-update.service

    x64Cru_150G:~ # 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 @13.896s
    └─display-manager.service @12.785s +1.110s
    └─systemd-user-sessions.service @12.743s +37ms
    └─network.target @12.739s
    └─wicked.service @5.461s +7.276s
    └─wickedd-nanny.service @5.420s +39ms
    └─wickedd.service @5.370s +49ms
    └─wickedd-auto4.service @5.316s +52ms
    └─network-pre.target @5.312s
    └─firewalld.service @4.729s +582ms
    └─polkit.service @4.478s +249ms
    └─basic.target @4.409s
    └─sockets.target @4.409s
    └─avahi-daemon.socket @4.408s
    └─sysinit.target @4.398s
    └─sys-fs-fuse-connections.mount @34.439s +3ms
    └─systemd-modules-load.service @255ms +37ms
    └─system.slice

    There is no info that I can detect in the Journal that tells me the reason for the long login. If the cannot be fixed I will have to abandon opensuse. Time is better after system updates, and I reboot that day. However, if system is off for several days then the login time returns to 5 minutes.

    regards,
    Bob
    Every now an then Leap runs the services marked above in bold. My machine does the same, but I don't notice any delays as they are running in background. Sddm is up and ready for login after a few seconds. Your systems waits until network is fully online. You may set WAIT_FOR_INTERFACES = 1 in file /etc/sysconfig/network/config

    Code:
    erlangen:~ # systemd-analyze critical-chain              
    The time when unit became active or started is printed after the "@" character. 
    The time the unit took to start is printed after the "+" character. 
    
    graphical.target @1.720s 
    └─display-manager.service @1.041s +678ms
      └─apache2.service @976ms +64ms
        └─time-sync.target @972ms 
          └─time-set.target @252ms 
    erlangen:~ #
    AMD Athlon 4850e (2009), openSUSE 13.1, KDE 4, Intel i3-4130 (2014), i7-6700K (2016), i5-8250U (2018), AMD Ryzen 5 3400G (2020), openSUSE Tumbleweed, KDE Plasma 5

  3. #3
    Join Date
    Dec 2008
    Location
    FL, USA
    Posts
    2,816
    Blog Entries
    1

    Default Re: leap 15.2 after upgrade kde taking over 5 minutes to start up from login

    What do OP's say for those long delay services? Mine:
    Code:
    # systemctl cat fstrim.timer
    # /usr/lib/systemd/system/fstrim.timer
    [Unit]
    Description=Discard unused blocks once a week
    Documentation=man:fstrim
    
    [Timer]
    OnCalendar=weekly
    AccuracySec=1h
    Persistent=true
    
    [Install]
    WantedBy=timers.target
    Code:
    # systemctl cat mandb.timer
    # /usr/lib/systemd/system/mandb.timer
    [Unit]
    Description=Do daily mandb update
    Documentation=man:mandb(8) man:catman(8)
    
    [Timer]
    OnCalendar=daily
    AccuracySec=12h
    Persistent=true
    
    [Install]
    WantedBy=timers.target
    Code:
    # systemctl cat backup-rpmdb.timer
    # /usr/lib/systemd/system/backup-rpmdb.timer
    [Unit]
    Description=Backup of RPM database
    After=local-fs.target
    
    [Timer]
    OnCalendar=daily
    AccuracySec=1m
    RandomizedDelaySec=2h
    Persistent=true
    
    [Install]
    WantedBy=timers.target
    Code:
    # systemd-analyze critical-chain
    ...
    multi-user.target @9.557s
    └─smb.service @9.467s +88ms
      └─nmb.service @9.371s +95ms
        └─network.target @9.349s
          └─wicked.service @4.437s +4.910s
            └─wickedd-nanny.service @4.424s +12ms
              └─wickedd.service @4.390s +31ms
                └─dbus.service @4.299s
                  └─basic.target @4.284s
                    └─paths.target @4.282s
                      └─cups.path @4.281s
                        └─sysinit.target @4.270s
                          └─systemd-timesyncd.service @4.212s +55ms
                            └─tmp.mount @3.791s +399ms
                              └─dev-disk-by\x2dlabel-hr18md0tmp.device @3.788s
    My native filesystems are all EXT4 (no BTRFS here).
    Reg. Linux User #211409 *** multibooting since 1992
    Primary: 15.2, +TW, 15.1, 15.0 & 13.1 on Haswell
    Secondary: eComStation (OS/2) &15.1 on i965P w/ Radeon
    Tertiary: Mageia,Fedora,Debian,more on Kaby Lake,iQ45,iQ43,iG41,iG3X,i965G,AMD,NVidia&&&&&

  4. #4
    Join Date
    Feb 2010
    Location
    Germany
    Posts
    4,052

    Question Re: leap 15.2 after upgrade kde taking over 5 minutes to start up from login

    Quote Originally Posted by bwheater View Post
    If the cannot be fixed I will have to abandon opensuse.
    You haven't mentioned how you performed the upgrade.


    Looking at your traces, there are a couple of items which may well take some time immediately following an upgrade – my recommendation is, to always manually perform these housekeeping chores immediately following the boot at the completion of the upgrade – preferable from a VT (tty1 .. tty6) logged in as the user “root” –
    • The systemd fstrim service – either “systemctl start fstrim.service” and then monitor progress with “systemctl status fstrim.service” or, “/usr/sbin/fstrim -Av” …
    • The “man” pages – either, simply “mandb” (several times to purge the caches) or, “systemctl start mandb.service” …
    • The RPM database backup – simply “systemctl start backup-rpmdb.service” – the CLI prompt will return when it has completed …


    And now, some numbers to help you prove to yourself that, openSUSE doesn't perform well –
    Code:
     # inxi --filter --cpu
    CPU:       Info: Quad Core model: AMD Ryzen 5 3400G with Radeon Vega Graphics bits: 64 type: MT MCP L2 cache: 2048 KiB 
               Speed: 1261 MHz min/max: 1400/3700 MHz Core speeds (MHz): 1: 1262 2: 1397 3: 1257 4: 1397 5: 1258 6: 1397 7: 1256 
               8: 1397 
     # inxi --filter --disk
    Drives:    Local Storage: total: 5.11 TiB used: 300.34 GiB (5.7%) 
               ID-1: /dev/sda vendor: Intenso model: SSD Sata III size: 111.79 GiB 
               ID-2: /dev/sdb vendor: Western Digital model: WD10EZEX-60M2NA0 size: 931.51 GiB 
               ID-3: /dev/sdc vendor: Western Digital model: WD40EZRZ-22GXCB0 size: 3.64 TiB 
               ID-4: /dev/sdd vendor: Seagate model: ST3500418AS size: 465.76 GiB 
     # inxi --filter --system
    System:    Kernel: 5.3.18-lp152.66-default x86_64 bits: 64 Console: tty 4 Distro: openSUSE Leap 15.2 
     # 
     # inxi --filter --memory
    Memory:    RAM: total: 13.57 GiB used: 4.22 GiB (31.1%) 
               Array-1: capacity: 128 GiB slots: 4 EC: None 
               Device-1: DIMM_A1 size: No Module Installed 
               Device-2: DIMM_A2 size: 8 GiB speed: 2133 MT/s 
               Device-3: DIMM_B1 size: No Module Installed 
               Device-4: DIMM_B2 size: 8 GiB speed: 2133 MT/s 
     # inxi --filter --machine
    Machine:   Type: Desktop Mobo: ASUSTeK model: PRIME B450-PLUS v: Rev X.0x serial: <filter> UEFI: American Megatrends v: 2807 
               date: 02/01/2021 
     # 
     # systemd-analyze
    Startup finished in 3.699s (kernel) + 1.086s (initrd) + 19.513s (userspace) = 24.299s
     # 
     # systemd-analyze blame | head
             12.726s wicked.service
              2.857s display-manager.service
              2.742s plymouth-quit-wait.service
              1.686s systemd-udev-settle.service
              1.660s systemd-journal-flush.service
              1.432s apparmor.service
              1.126s nfs-server.service
               832ms udisks2.service
               822ms mandb.service
               685ms smartd.service
     # systemd-analyze blame | grep -iE 'fstrim|backup|mandb'
               822ms mandb.service
               604ms backup-rpmdb.service
               197ms backup-sysconfig.service
     # systemctl status fstrim.timer 
    ● fstrim.timer - Discard unused blocks once a month
       Loaded: loaded (/etc/systemd/system/fstrim.timer; enabled; vendor preset: enabled)
       Active: active (waiting) since Wed 2021-04-07 09:38:20 CEST; 9h ago
      Trigger: Sat 2021-05-01 00:00:00 CEST; 3 weeks 2 days left
         Docs: man:fstrim
    
    Apr 07 09:38:20 eck001 systemd[1]: Started Discard unused blocks once a month.
     #
    • This morning, “Wicked” was about 3 seconds slower than normal – maybe an IPv6 issue today …

  5. #5

    Default Re: leap 15.2 after upgrade kde taking over 5 minutes to start up from login

    KDE started up in less than 5 seconds today but the system was only off for less than 24 hour. Usually the problem occurs when it is off for several days.

    Also, your responses are focusing on the "wrong" part of startup. The SDDM login screen comes up fast enough. The problem is between hitting the return key on the password and when the KDE taskbar become responsive (that is the only part that is slow and can take up to 5 minutes when the problem occurs).

    I try your suggested commands as shown below:
    Code:
    My responses are marked with ">>"
    
    Every now an then Leap runs the services marked above in bold. My machine 
    does the same, but I don't notice any delays as they are running in 
    background. Sddm is up and ready for login after a few seconds. Your 
    systems waits until network is fully online. You may set 
    WAIT_FOR_INTERFACES = 1 in file /etc/sysconfig/network/config
    
    >>network startup is before KDE and any delays in seconds are 
    insignificant compared to the 5 minutes from typing the password, hitting 
    <return key> and the task bar of KDE is responsive.
    
    You haven't mentioned how you performed the upgrade.
    
    >>essentially the same as your link. used 
    https://linuxkamarada.com/en/2020/09/01/linux-kamarada-and-opensuse-leap-
    how-to-upgrade-from-151-to-152/ ignoring the Kamarada related stuff. This 
    avoids having to use the command line for part of the work.  By the way I 
    hate how complicated opensuse upgrade is compared to Ubuntu.
    
        I've never noticed the 5 minutes and more periods you've mentioned when 
    upgrading by means of the DVD with network access to the update 
    repositories.
    >> no DVD needed.
        And, the procedures in the following SDB articles are strongly 
    recommended – <https://en.opensuse.org/SDB:Offline_upgrade>; 
    <https://en.opensuse.org/SDB:System_upgrade>. 
    
    systemctl start fstrim.service
    x64Cru_150G:~ # systemctl status fstrim.service
    ● fstrim.service - Discard unused blocks on filesystems from /etc/fstab
       Loaded: loaded (/usr/lib/systemd/system/fstrim.service; static; vendor 
    preset: disabled)
       Active: inactive (dead) since Thu 2021-04-08 15:37:38 EDT; 6s ago
         Docs: man:fstrim(8)
      Process: 14701 ExecStart=/usr/sbin/fstrim -Av (code=exited, 
    status=0/SUCCESS)
     Main PID: 14701 (code=exited, status=0/SUCCESS)
    
    Apr 08 15:36:25 x64Cru_150G systemd[1]: Starting Discard unused blocks on 
    filesystems from /etc/fstab...
    Apr 08 15:37:38 x64Cru_150G fstrim[14701]: /Backups: 405.8 GiB 
    (435671740416 bytes) trimmed on /dev/mapper/CT500MX500SSD1_18>
    Apr 08 15:37:38 x64Cru_150G fstrim[14701]: /boot/efi: 492.1 MiB (516014080 
    bytes) trimmed on /dev/mapper/CT500MX500SSD1_1819>
    Apr 08 15:37:38 x64Cru_150G fstrim[14701]: /home: 45.9 GiB (49271521280 
    bytes) trimmed on /dev/mapper/CT500MX500SSD1_1819E13>
    Apr 08 15:37:38 x64Cru_150G fstrim[14701]: /: 122.6 GiB (131674869760 
    bytes) trimmed on /dev/mapper/CT500MX500SSD1_1819E13C3>
    Apr 08 15:37:38 x64Cru_150G systemd[1]: Started Discard unused blocks on 
    filesystems from /etc/fstab.
    
    mandb
    Purging old database entries in /usr/share/man/ca...
    Processing manual pages under /usr/share/man/ca...
    Purging old database entries in /usr/share/man/cs...
    Processing manual pages under /usr/share/man/cs...
    Purging old database entries in /usr/share/man/da...
    Processing manual pages under /usr/share/man/da...
    Purging old database entries in /usr/share/man/de...
    Processing manual pages under /usr/share/man/de...
    Purging old database entries in /usr/share/man/es...
    Processing manual pages under /usr/share/man/es...
    Purging old database entries in /usr/share/man/et...
    Processing manual pages under /usr/share/man/et...
    Purging old database entries in /usr/share/man/it...
    Processing manual pages under /usr/share/man/it...
    Purging old database entries in /usr/share/man/ja...
    Processing manual pages under /usr/share/man/ja...
    Purging old database entries in /usr/share/man/nl...
    Processing manual pages under /usr/share/man/nl...
    Purging old database entries in /usr/share/man/pl...
    Processing manual pages under /usr/share/man/pl...
    Purging old database entries in /usr/share/man/pt...
    Processing manual pages under /usr/share/man/pt...
    Purging old database entries in /usr/share/man/pt_BR...
    Processing manual pages under /usr/share/man/pt_BR...
    Purging old database entries in /usr/share/man/ru...
    Processing manual pages under /usr/share/man/ru...
    Purging old database entries in /usr/share/man/sk...
    Processing manual pages under /usr/share/man/sk...
    Purging old database entries in /usr/share/man/sr...
    Processing manual pages under /usr/share/man/sr...
    Purging old database entries in /usr/share/man/sv...
    Processing manual pages under /usr/share/man/sv...
    Purging old database entries in /usr/share/man/uk...
    Processing manual pages under /usr/share/man/uk...
    Purging old database entries in /usr/share/man...
    Processing manual pages under /usr/share/man...
    Purging old database entries in /usr/share/man/ca...
    Processing manual pages under /usr/share/man/ca...
    Purging old database entries in /usr/share/man/cs...
    Processing manual pages under /usr/share/man/cs...
    Purging old database entries in /usr/share/man/da...
    Processing manual pages under /usr/share/man/da...
    Purging old database entries in /usr/share/man/de...
    Processing manual pages under /usr/share/man/de...
    Purging old database entries in /usr/share/man/el...
    Processing manual pages under /usr/share/man/el...
    Purging old database entries in /usr/share/man/eo...
    Processing manual pages under /usr/share/man/eo...
    Purging old database entries in /usr/share/man/es...
    Processing manual pages under /usr/share/man/es...
    Purging old database entries in /usr/share/man/fr...
    Processing manual pages under /usr/share/man/fr...
    Purging old database entries in /usr/share/man/hu...
    Processing manual pages under /usr/share/man/hu...
    Purging old database entries in /usr/share/man/it...
    Processing manual pages under /usr/share/man/it...
    Purging old database entries in /usr/share/man/ja...
    Processing manual pages under /usr/share/man/ja...
    Purging old database entries in /usr/share/man/nl...
    Processing manual pages under /usr/share/man/nl...
    Purging old database entries in /usr/share/man/pl...
    Processing manual pages under /usr/share/man/pl...
    Purging old database entries in /usr/share/man/pt...
    Processing manual pages under /usr/share/man/pt...
    Purging old database entries in /usr/share/man/pt_BR...
    Processing manual pages under /usr/share/man/pt_BR...
    Purging old database entries in /usr/share/man/ru...
    Processing manual pages under /usr/share/man/ru...
    Purging old database entries in /usr/share/man/sk...
    Processing manual pages under /usr/share/man/sk...
    Purging old database entries in /usr/share/man/sv...
    Processing manual pages under /usr/share/man/sv...
    Purging old database entries in /usr/share/man/zh...
    Processing manual pages under /usr/share/man/zh...
    Purging old database entries in /usr/share/man/zh_CN...
    Processing manual pages under /usr/share/man/zh_CN...
    Purging old database entries in /usr/share/man/zh_TW...
    Processing manual pages under /usr/share/man/zh_TW...
    Purging old database entries in /usr/share/man/uk...
    Processing manual pages under /usr/share/man/uk...
    Purging old database entries in /usr/share/man/fr.ISO8859-1...
    Processing manual pages under /usr/share/man/fr.ISO8859-1...
    Purging old database entries in /usr/share/man/fr.UTF-8...
    Processing manual pages under /usr/share/man/fr.UTF-8...
    Purging old database entries in /usr/share/man/id...
    Processing manual pages under /usr/share/man/id...
    Purging old database entries in /usr/share/man/et...
    Processing manual pages under /usr/share/man/et...
    Purging old database entries in /usr/share/man/sr...
    Processing manual pages under /usr/share/man/sr...
    Purging old database entries in /usr/share/man/tr...
    Processing manual pages under /usr/share/man/tr...
    Purging old database entries in /usr/share/man/nb...
    Processing manual pages under /usr/share/man/nb...
    Purging old database entries in /usr/share/man/gl...
    Processing manual pages under /usr/share/man/gl...
    Purging old database entries in /usr/share/man/sr@latin...
    Processing manual pages under /usr/share/man/sr@latin...
    Processing manual pages under /usr/local/man...
    Updating index cache for path `/usr/local/man/man1'. Wait...
    Updating index cache for path `/usr/local/man/man2'. Wait...
    Updating index cache for path `/usr/local/man/man3'. Wait...
    Updating index cache for path `/usr/local/man/man4'. Wait...
    Updating index cache for path `/usr/local/man/man5'. Wait...
    Updating index cache for path `/usr/local/man/man6'. Wait...
    Updating index cache for path `/usr/local/man/man7'. Wait...
    Updating index cache for path `/usr/local/man/man8'. Wait...
    Updating index cache for path `/usr/local/man/man9'. Wait...
    Updating index cache for path `/usr/local/man/mann'. Wait...
    done.
    Checking for stray cats under /usr/local/man...
    Checking for stray cats under /var/cache/man/local...
    10 man subdirectories contained newer manual pages.
    0 manual pages were added.
    0 stray cats were added.
    0 old database entries were purged.
    
    x64Cru_150G:~ # systemctl start backup-rpmdb.service
    x64Cru_150G:~ # systemctl status backup-rpmdb.service
    ● backup-rpmdb.service - Backup RPM database
       Loaded: loaded (/usr/lib/systemd/system/backup-rpmdb.service; static; 
    vendor preset: disabled)
       Active: inactive (dead) since Thu 2021-04-08 16:00:45 EDT; 10s ago
      Process: 15101 ExecStart=/usr/lib/base-scripts/backup-rpmdb (code=exited, 
    status=0/SUCCESS)
     Main PID: 15101 (code=exited, status=0/SUCCESS)
    
    Apr 08 16:00:32 x64Cru_150G systemd[1]: Starting Backup RPM database...
    Apr 08 16:00:45 x64Cru_150G systemd[1]: Started Backup RPM database.
    x64Cru_150G:~ # inxi --filter --cpu
    CPU:       Topology: 6-Core model: Intel Core i7-8700K bits: 64 type: MT 
    MCP L2 cache: 12.0 MiB 
               Speed: 800 MHz min/max: 800/4700 MHz Core speeds (MHz): 1: 801 
    2: 801 3: 800 4: 800 5: 801 6: 801 7: 800 
               8: 800 9: 800 10: 800 11: 800 12: 800 
    x64Cru_150G:~ # inxi --filter --disk
    Drives:    Local Storage: total: 1.36 TiB used: 97.47 GiB (7.0%) 
               ID-1: /dev/nvme0n1 vendor: Samsung model: SSD 960 EVO 500GB 
    size: 465.76 GiB 
               ID-2: /dev/nvme1n1 vendor: Samsung model: SSD 960 EVO 500GB 
    size: 465.76 GiB 
               ID-3: /dev/sda vendor: Crucial model: CT500MX500SSD1 size: 
    465.76 GiB 
               ID-4: /dev/sdb vendor: Crucial model: CT500MX500SSD1 size: 
    465.76 GiB 
    x64Cru_150G:~ # inxi --filter --system
    System:    Kernel: 5.3.18-lp152.66-default x86_64 bits: 64 Console: tty 1 
    Distro: openSUSE Leap 15.2 
    x64Cru_150G:~ # inxi --filter --machine
    Machine:   Type: Desktop Mobo: Micro-Star model: Z370M GAMING PRO AC 
    (MS-7B44) v: 1.0 serial: <filter> 
               UEFI: American Megatrends v: 1.20 date: 12/21/2017 
    x64Cru_150G:~ # systemd-analyze blame
        1min 13.428s fstrim.service
             13.035s backup-rpmdb.service
              7.515s mlocate.service
              7.342s wicked.service
              4.262s systemd-udev-settle.service
              3.095s lvm2-monitor.service
              2.340s display-manager.service
              1.190s ca-certificates.service
              1.078s systemd-tmpfiles-setup-dev.service
              1.070s postfix.service
               953ms systemd-udevd.service
               882ms apparmor.service
               757ms polkit.service
               738ms firewalld.service
               685ms dracut-initqueue.service
               642ms systemd-sysctl.service
               538ms logrotate.service
               458ms initrd-switch-root.service
               336ms ModemManager.service
               249ms rsyslog.service
               222ms systemd-journal-flush.service
    x64Cru_150G:~ # 
    
    None of the above service times are related to time it take KDE to startup
    regards,
    Bob

  6. #6
    Join Date
    Dec 2008
    Location
    FL, USA
    Posts
    2,816
    Blog Entries
    1

    Default Re: leap 15.2 after upgrade kde taking over 5 minutes to start up from login

    Try this:
    1. log out of X
    2. Ctrl-Alt-F3
    3. login
    4. rm .xsession-errors
    5. rm -R .cache/*
    6. log out
    7. Alt-F7
    8. login to Plasma
    9. ASAP, open Konsole or Xterm
    10. in Konsole or Xterm: susepaste .xsession-errors
    11. sudo journalctl -b | egrep 'lasma|kde' | susepaste
    12. report here the URLs resulting from the susepaste commands
    Reg. Linux User #211409 *** multibooting since 1992
    Primary: 15.2, +TW, 15.1, 15.0 & 13.1 on Haswell
    Secondary: eComStation (OS/2) &15.1 on i965P w/ Radeon
    Tertiary: Mageia,Fedora,Debian,more on Kaby Lake,iQ45,iQ43,iG41,iG3X,i965G,AMD,NVidia&&&&&

  7. #7
    Join Date
    Oct 2014
    Location
    Switzerland
    Posts
    851

    Default Re: leap 15.2 after upgrade kde taking over 5 minutes to start up from login

    Ah, I ran into this problem a while ago: https://forums.opensuse.org/showthre...strim-service-!

    The conclusion is that you probably have trimmable shingled HDD like WD blue 2.5" 2TB or something. Look at page 3~5 of (https://forums.opensuse.org/showthre...strim-service-!) for solution. You need to modify your fstrim.service to not run over all of your partitions but only the partitions on your SSD.

  8. #8

    Default Re: leap 15.2 after upgrade kde taking over 5 minutes to start up from login

    To the last reply: all my devices in fstab are SSD's -- so that all need periodic trims but why do it during bootup?.

    I had a long boot up time "today" apparently due to fstrim and mandb. Apparently fstrim is scheduled once a week and mandb is daily. I don't understand why 15.1 did not have the problem. Is there a way to defer these services to after bootup is complete? Does mandb need to be daily? Are there any other suggestions to improve the bootup time with regard so fstrim and mandb as they are taking the most time: 13 minutes. Also is the fstrim time reasonable on a sata SSD (CRUCIAL) for the amount of storage released? All my SSD are 512GB. Will excess trims on the drive shorted it life?

    Code:
    bob1@x64Cru_150G:~/Documents/Problems> cat 042021SlowStartupSystemDblame.log
    Slow start from typing password in SDDM until KDE response.
    
    
    systemd-analyze blame | cat
        7min 46.764s fstrim.service
        6min 40.995s mandb.service
             14.353s backup-rpmdb.service
              7.496s wicked.service
              4.300s mlocate.service
              2.703s logrotate.service
              2.243s systemd-udev-settle.service
              1.121s display-manager.service
              1.042s apparmor.service
               830ms postfix.service
               686ms dracut-initqueue.service
               667ms lvm2-monitor.service
               667ms firewalld.service
               642ms ca-certificates.service
               622ms initrd-switch-root.service
               322ms ModemManager.service
               237ms systemd-journal-flush.service
               229ms backup-sysconfig.service
               209ms upower.service
               182ms udisks2.service
               181ms rsyslog.service
               176ms polkit.service
               167ms smartd.service
               167ms plymouth-read-write.service
               166ms user@1001.service
               120ms systemd-timesyncd.service
               109ms systemd-vconsole-setup.service
               100ms systemd-sysctl.service
                97ms sshd.service
                96ms lm_sensors.service
                93ms home.mount
                90ms iscsi.service
                89ms initrd-parse-etc.service
                85ms mcelog.service
                83ms klog.service
                80ms kbdsettings.service
                80ms avahi-daemon.service
                80ms systemd-logind.service
                79ms alsa-restore.service
                72ms bluetooth.service
                66ms rtkit-daemon.service
                64ms systemd-udev-trigger.service
                60ms wickedd-auto4.service
                59ms systemd-tmpfiles-setup.service
                56ms wickedd-dhcp4.service
                55ms wickedd-dhcp6.service
                54ms systemd-udevd.service
                53ms systemd-rfkill.service
                45ms systemd-modules-load.service
                45ms systemd-journald.service
                45ms wickedd.service
                44ms systemd-random-seed.service
                44ms systemd-tmpfiles-setup-dev.service
                43ms multipathd.service
                43ms systemd-user-sessions.service
                43ms dev-disk-by\x2duuid-c198baa7\x2dc779\x2d43cd\x2db552\x2dd10aa4031bd1.swap
                40ms systemd-update-utmp.service
                39ms wickedd-nanny.service
                37ms systemd-remount-fs.service
                36ms user-runtime-dir@1001.service
                36ms systemd-update-utmp-runlevel.service
                29ms dracut-cmdline.service
                23ms sysroot.mount
                23ms chronyd.service
                22ms initrd-cleanup.service
                22ms dracut-pre-udev.service
                21ms sys-kernel-debug.mount
                21ms dev-mqueue.mount
                20ms boot-efi.mount
                19ms auditd.service
                18ms dracut-pre-pivot.service
                17ms boot-grub2-x86_64\x2defi.mount
                17ms dev-hugepages.mount
                16ms Backups.mount
                15ms plymouth-switch-root.service
                14ms \x2esnapshots.mount
                13ms kmod-static-nodes.service
                13ms srv.mount
                12ms boot-grub2-i386\x2dpc.mount
                12ms nscd.service
                10ms systemd-fsck-root.service
                10ms tmp.mount
                 9ms var.mount
                 9ms opt.mount
                 9ms usr-local.mount
                 7ms dracut-shutdown.service
                 6ms root.mount
                 6ms check-battery.service
                 3ms initrd-udevadm-cleanup-db.service
                 2ms sys-fs-fuse-connections.mount
                 1ms plymouth-quit-wait.service
    x64Cru_150G:~ # 
    
    
    
    
    x64Cru_150G:~ #  systemd-analyze critical-chain | cat
    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 @13.572s
    └─display-manager.service @12.450s +1.121s
      └─systemd-user-sessions.service @12.403s +43ms
        └─network.target @12.402s
          └─wicked.service @4.904s +7.496s
            └─wickedd-nanny.service @4.864s +39ms
              └─wickedd.service @4.817s +45ms
                └─wickedd-auto4.service @4.756s +60ms
                  └─network-pre.target @4.754s
                    └─firewalld.service @4.087s +667ms
                      └─polkit.service @3.909s +176ms
                        └─basic.target @3.892s
                          └─paths.target @3.891s
                            └─btrfsmaintenance-refresh.path @3.889s
                              └─sysinit.target @3.871s
                                └─sys-fs-fuse-connections.mount @32.994s +2ms
                                  └─systemd-modules-load.service @402ms +45ms
                                    └─system.slice
                                      └─-.slice
    
    
    x64Cru_150G:~ # systemctl cat fstrim.service
    # /usr/lib/systemd/system/fstrim.service
    [Unit]
    Description=Discard unused blocks on filesystems from /etc/fstab
    Documentation=man:fstrim(8)
    
    [Service]
    Type=oneshot
    ExecStart=/usr/sbin/fstrim -Av
    
    x64Cru_150G:~ # systemctl cat fstrim.timer
    # /usr/lib/systemd/system/fstrim.timer
    [Unit]
    Description=Discard unused blocks once a week
    Documentation=man:fstrim
    
    [Timer]
    OnCalendar=weekly
    AccuracySec=1h
    Persistent=true
    
    [Install]
    WantedBy=timers.target
    
    
    x64Cru_150G:~ # systemctl status fstrim.service | cat
    ● fstrim.service - Discard unused blocks on filesystems from /etc/fstab
       Loaded: loaded (/usr/lib/systemd/system/fstrim.service; static; vendor preset: disabled)
       Active: inactive (dead) since Tue 2021-04-20 15:33:03 EDT; 55min ago
         Docs: man:fstrim(8)
     Main PID: 2462 (code=exited, status=0/SUCCESS)
    
    Apr 20 15:25:22 x64Cru_150G systemd[1]: Starting Discard unused blocks on filesystems from /etc/fstab...
    Apr 20 15:33:03 x64Cru_150G fstrim[2462]: /Backups: 405.8 GiB (435671740416 bytes) trimmed on /dev/mapper/CT500MX500SSD1_1819E13BED1C-part1
    Apr 20 15:33:03 x64Cru_150G fstrim[2462]: /boot/efi: 492.1 MiB (516014080 bytes) trimmed on /dev/mapper/CT500MX500SSD1_1819E13C3613-part1
    Apr 20 15:33:03 x64Cru_150G fstrim[2462]: /home: 45.8 GiB (49146339328 bytes) trimmed on /dev/mapper/CT500MX500SSD1_1819E13C3613-part4
    Apr 20 15:33:03 x64Cru_150G fstrim[2462]: /: 120.8 GiB (129720602624 bytes) trimmed on /dev/mapper/CT500MX500SSD1_1819E13C3613-part2
    Apr 20 15:33:03 x64Cru_150G systemd[1]: Started Discard unused blocks on filesystems from /etc/fstab.
    =======================================
    
    
    x64Cru_150G:~ # systemctl cat mandb.service
    # /usr/lib/systemd/system/mandb.service
    [Unit]
    Description=Do daily mandb update
    Documentation=man:mandb(8) man:catman(8)
    ConditionACPower=true
    
    [Service]
    Type=oneshot
    Nice=5
    IOSchedulingClass=idle
    ExecStart=/usr/lib/man-db/do_mandb
    
    
    
    x64Cru_150G:~ # systemctl cat mandb.timer
    # /usr/lib/systemd/system/mandb.timer
    [Unit]
    Description=Do daily mandb update
    Documentation=man:mandb(8) man:catman(8)
    
    [Timer]
    OnCalendar=daily
    AccuracySec=12h
    Persistent=true
    
    [Install]
    WantedBy=timers.target
    
    
    =======================================
    
    WantedBy=timers.targetx64Cru_150G:~ # systemctl status mandb
    ● mandb.service - Do daily mandb update
       Loaded: loaded (/usr/lib/systemd/system/mandb.service; static; vendor preset: disabled)
       Active: inactive (dead) since Tue 2021-04-20 15:31:57 EDT; 2h 1min ago
         Docs: man:mandb(8)
               man:catman(8)
     Main PID: 2464 (code=exited, status=0/SUCCESS)
    
    Apr 20 15:25:22 x64Cru_150G systemd[1]: Starting Do daily mandb update...
    Apr 20 15:31:57 x64Cru_150G systemd[1]: Started Do daily mandb update.
    
    bob1@x64Cru_150G:~/Documents/Problems> 
    
    x64Cru_150G:~ # cat /etc/fstab
    UUID=b89f2cdf-1fad-4511-b5dd-6b21ab1d7df6  /                       btrfs  defaults                      0  0
    UUID=b89f2cdf-1fad-4511-b5dd-6b21ab1d7df6  /.snapshots             btrfs  subvol=/@/.snapshots          0  0
    UUID=c198baa7-c779-43cd-b552-d10aa4031bd1  swap                    swap   defaults                      0  0
    UUID=b89f2cdf-1fad-4511-b5dd-6b21ab1d7df6  /var                    btrfs  subvol=/@/var                 0  0
    UUID=b89f2cdf-1fad-4511-b5dd-6b21ab1d7df6  /usr/local              btrfs  subvol=/@/usr/local           0  0
    UUID=b89f2cdf-1fad-4511-b5dd-6b21ab1d7df6  /tmp                    btrfs  subvol=/@/tmp                 0  0
    UUID=b89f2cdf-1fad-4511-b5dd-6b21ab1d7df6  /srv                    btrfs  subvol=/@/srv                 0  0
    UUID=b89f2cdf-1fad-4511-b5dd-6b21ab1d7df6  /root                   btrfs  subvol=/@/root                0  0
    UUID=b89f2cdf-1fad-4511-b5dd-6b21ab1d7df6  /opt                    btrfs  subvol=/@/opt                 0  0
    UUID=da0b4f67-dba4-4ba6-9ccf-a6e1a80a0fa2  /home                   xfs    defaults                      0  0
    UUID=b89f2cdf-1fad-4511-b5dd-6b21ab1d7df6  /boot/grub2/x86_64-efi  btrfs  subvol=/@/boot/grub2/x86_64-efi  0  0
    UUID=b89f2cdf-1fad-4511-b5dd-6b21ab1d7df6  /boot/grub2/i386-pc     btrfs  subvol=/@/boot/grub2/i386-pc  0  0
    UUID=1DF4-67A1                             /boot/efi               vfat   defaults                      0  0
    UUID=ad2e7eb2-f3a9-4af8-aac7-756d5239a9d6  /Backups                ext4   defaults                      0  0

  9. #9
    Join Date
    Jan 2014
    Location
    Erlangen
    Posts
    2,493
    Blog Entries
    1

    Default Re: leap 15.2 after upgrade kde taking over 5 minutes to start up from login

    Quote Originally Posted by bwheater View Post
    I had a long boot up time "today" apparently due to fstrim and mandb. Apparently fstrim is scheduled once a week and mandb is daily. I don't understand why 15.1 did not have the problem. Is there a way to defer these services to after bootup is complete? Does mandb need to be daily? Are there any other suggestions to improve the bootup time with regard so fstrim and mandb as they are taking the most time: 13 minutes. Also is the fstrim time reasonable on a sata SSD (CRUCIAL) for the amount of storage released? All my SSD are 512GB. Will excess trims on the drive shorted it life?
    Machines vastly differ in hardware components:
    Code:
    erlangen:~ # inxi -zFm 
    System:    Kernel: 5.11.15-1-default x86_64 bits: 64 Console: tty pts/1 Distro: openSUSE Tumbleweed 20210418  
    Machine:   Type: Desktop Mobo: ASRock model: Z170 Pro4S serial: <filter> UEFI: American Megatrends v: P3.50 date: 06/23/2016  
    Memory:    RAM:total: 31.3 GiB used: 4.33 GiB (13.8%)  
               Array-1:capacity: 64 GiB slots: 4 EC: None  
               Device-1: ChannelA-DIMM0 size: No Module Installed  
               Device-2: ChannelA-DIMM1 size: 16 GiB speed: 2133 MT/s  
               Device-3: ChannelB-DIMM0 size: No Module Installed  
               Device-4: ChannelB-DIMM1 size: 16 GiB speed: 2133 MT/s  
    CPU:       Info: Quad Core model: Intel Core i7-6700K bits: 64 type: MT MCP cache:L2: 8 MiB  
               Speed: 800 MHz min/max: 800/4200 MHz Core speeds (MHz):1: 800 2: 800 3: 800 4: 800 5: 800 6: 800 7: 800 8: 800  
    Graphics:  Device-1: AMD Lexa PRO [Radeon 540/540X/550/550X / RX 540X/550/550X] driver: amdgpu v: kernel  
               Display:server: X.Org 1.20.10 driver:loaded: amdgpu,ati unloaded: fbdev,modesetting,vesa  
               resolution: 3840x2160~60Hz  
               OpenGL:renderer: Radeon RX550/550 Series (POLARIS12 DRM 3.40.0 5.11.15-1-default LLVM 11.0.1) v: 4.6 Mesa 21.0.2  
    Audio:     Device-1: Intel 100 Series/C230 Series Family HD Audio driver: snd_hda_intel  
               Device-2: AMD Baffin HDMI/DP Audio [Radeon RX 550 640SP / RX 560/560X] driver: snd_hda_intel  
               Sound Server-1: ALSA v: k5.11.15-1-default running: yes  
               Sound Server-2: PulseAudio v: 14.2-rebootstrapped running: yes  
    Network:   Device-1: Intel Ethernet I219-V driver: e1000e  
               IF: enp0s31f6 state: up speed: 1000 Mbps duplex: full mac: <filter>  
    Drives:    Local Storage:total: 6.38 TiB used: 3.13 TiB (49.1%)  
               ID-1: /dev/nvme0n1 vendor: Samsung model: SSD 950 PRO 512GB size: 476.94 GiB  
               ID-2: /dev/sda vendor: Western Digital model: WD40EZRX-22SPEB0 size: 3.64 TiB  
               ID-3: /dev/sdb vendor: Crucial model: CT2000BX500SSD1 size: 1.82 TiB  
               ID-4: /dev/sdc vendor: Samsung model: SSD 850 EVO 500GB size: 465.76 GiB  
    Partition: ID-1: / size: 51.69 GiB used: 21.96 GiB (42.5%) fs: btrfs dev: /dev/nvme0n1p3  
               ID-2: /boot/efi size: 99.8 MiB used: 15.3 MiB (15.3%) fs: vfat dev: /dev/nvme0n1p1  
               ID-3: /home size: 406.34 GiB used: 292.62 GiB (72.0%) fs: ext4 dev: /dev/nvme0n1p4  
               ID-4: /opt size: 51.69 GiB used: 21.96 GiB (42.5%) fs: btrfs dev: /dev/nvme0n1p3  
               ID-5: /var size: 51.69 GiB used: 21.96 GiB (42.5%) fs: btrfs dev: /dev/nvme0n1p3  
    Swap:      Alert: No Swap data was found.  
    Sensors:   System Temperatures:cpu: 32.0 C mobo: 33.0 C gpu: amdgpu temp: 53.0 C  
               Fan Speeds (RPM):fan-1: 0 fan-2: 1187 fan-3: 0 fan-4: 0 fan-5: 0 fan-6: 0 gpu: amdgpu fan: 965  
    Info:      Processes: 280 Uptime: 9h 51m Shell: Bash inxi: 3.3.03  
    erlangen:~ #
    On host erlangen many services are running in parallel. Nevertheless no delay occurs on boot up in kde:
    Code:
    erlangen:~ # systemd-analyze blame |head -22  
    2min 11.285s backup-home.service                  
         36.554s purge-kernels.service                
         28.072s mlocate.service                      
         15.711s backup-rpmdb.service                 
          9.949s HDD.mount                            
          8.733s mandb.service                        
          1.540s logrotate.service                    
           963ms dracut-initqueue.service             
           909ms dracut-pre-udev.service              
           708ms display-manager.service              
           587ms initrd-switch-root.service           
           552ms postfix.service                      
           448ms udisks2.service                      
           391ms lm_sensors.service                   
           318ms systemd-journal-flush.service        
           292ms apparmor.service                     
           287ms plymouth-quit-wait.service           
           209ms systemd-resolved.service             
           202ms initrd-parse-etc.service             
           177ms mcelog.service                       
           139ms systemd-logind.service               
           135ms user@1000.service                    
    erlangen:~ #
    Display manager is up early. Login and startup of the graphical session is fast:
    Code:
    erlangen:~ # systemd-analyze critical-chain display-manager.service              
    The time when unit became active or started is printed after the "@" character. 
    The time the unit took to start is printed after the "+" character. 
    
    display-manager.service +708ms 
    └─apache2.service @1.055s +68ms 
      └─time-sync.target @1.050s 
        └─chronyd.service @1.019s +30ms 
          └─nss-lookup.target @1.018s 
            └─systemd-resolved.service @809ms +209ms 
              └─systemd-tmpfiles-setup.service @792ms +15ms 
                └─systemd-journal-flush.service @473ms +318ms 
                  └─var.mount @464ms +7ms 
                    └─local-fs-pre.target @457ms 
                      └─systemd-tmpfiles-setup-dev.service @442ms +14ms 
                        └─kmod-static-nodes.service @400ms +32ms 
                          └─systemd-journald.socket 
                            └─-.mount 
                              └─system.slice 
                                └─-.slice 
    erlangen:~ #
    Fstrim runs in the background and I never notice any delays of the graphical interface:
    Code:
    erlangen:~ # journalctl -b -1 -u fstrim.service
    -- Logs begin at Wed 2021-03-24 04:52:44 CET, end at Wed 2021-04-21 06:33:08 CEST. --
    Apr 19 05:39:00 erlangen systemd[1]: Starting Discard unused blocks on filesystems from /etc/fstab...
    Apr 19 05:45:11 erlangen fstrim[4578]: /home-SSD: 575,4 GiB (617788227584 Bytes) auf /dev/sdb1 getrimmt
    Apr 19 05:45:11 erlangen fstrim[4578]: /boot/efi: 84,5 MiB (88600576 Bytes) auf /dev/nvme0n1p1 getrimmt
    Apr 19 05:45:11 erlangen fstrim[4578]: /home: 113,7 GiB (122039463936 Bytes) auf /dev/nvme0n1p4 getrimmt
    Apr 19 05:45:11 erlangen fstrim[4578]: /: 11,1 GiB (11904901120 Bytes) auf /dev/nvme0n1p3 getrimmt
    Apr 19 05:45:11 erlangen systemd[1]: fstrim.service: Succeeded.
    Apr 19 05:45:11 erlangen systemd[1]: Finished Discard unused blocks on filesystems from /etc/fstab.
    Apr 19 05:45:11 erlangen systemd[1]: fstrim.service: Consumed 8.403s CPU time.
    erlangen:~ #
    Sizes of trimmed partition are:
    Code:
    erlangen:~ # df -h 
    Filesystem      Size  Used Avail Use% Mounted on 
    /dev/nvme0n1p3   52G   22G   28G  45% / 
    /dev/nvme0n1p1  100M   16M   85M  16% /boot/efi
    /dev/nvme0n1p4  407G  293G  113G  73% /home 
    /dev/sdb1       1.8T  1.3T  483G  73% /home-SSD 
    erlangen:~ #
    Btrfs maintenance is also fast and unobtrusive:
    Code:
    erlangen:~ # journalctl -b -u btrfs* --grep Consumed
    -- Logs begin at Wed 2021-03-24 04:52:44 CET, end at Wed 2021-04-21 06:33:08 CEST. --
    Apr 21 05:12:50 erlangen systemd[1]: btrfs-defrag.service: Consumed 7.940s CPU time.
    Apr 21 05:13:52 erlangen systemd[1]: btrfs-trim.service: Consumed 3.144s CPU time.
    Apr 21 05:14:05 erlangen systemd[1]: btrfs-scrub.service: Consumed 4.041s CPU time.
    erlangen:~ #
    I presume your machine runs out of resources. Of course you always can run your services at your own schedule. Modify the timers accordingly.
    AMD Athlon 4850e (2009), openSUSE 13.1, KDE 4, Intel i3-4130 (2014), i7-6700K (2016), i5-8250U (2018), AMD Ryzen 5 3400G (2020), openSUSE Tumbleweed, KDE Plasma 5

  10. #10
    Join Date
    Feb 2010
    Location
    Germany
    Posts
    4,052

    Default Re: leap 15.2 after upgrade kde taking over 5 minutes to start up from login

    Quote Originally Posted by bwheater View Post
    Does mandb need to be daily?
    Depends on how often the packages containing man pages are updated – if no packages have been updated then, the mandb service doesn't impact the boot time –
    • Assuming that, the system was shut down over night – it wasn't running at midnight – which is when the mandb Timer service triggers …
    • If the system is running at midnight then, the mandb service will trigger at midnight …

    Does it need to run (at all)?
    • Yes – if it doesn't any updates to the man pages which haven't been inserted into the “man” database will result in unwelcome, unexpected “man” and “apropos” behaviour …

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •