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

Thread: Login Time

  1. #1
    Join Date
    Apr 2013
    Location
    Sydney, AU
    Posts
    245

    Default Login Time

    Having upgraded to Leap 15.2 i notice that the time required to log in to the User Interface after supplying a password seems to take a long time (~40 secs)


    Booting the system to the log in screen occurs thus:


    $ systemd-analyze
    Startup finished in 3.340s (kernel) + 1.810s (initrd) + 26.113s (userspace) = 31.264s


    ... but from there i am unable to analyse what is taking a further 40 secs or so after supplying the password at the logon screen.


    'Restore previous session' does not apply as the login process is configured to 'Start with an empty session' each time.


    Is there some way to analyse just what is being done between supplying the password and having the UI presented for use??


    Thanks.
    openSUSE Leap 15.2 | KDE Plasma 5.18.5 | Frameworks 5.71.0 | Qt 5.12.7 | Kernel 5.3.18-lp152.19-default | Procs 4 x i5-2500 CPU @ 3.3.GHz | 15.6 GiB RAM | 4 Monitors

  2. #2
    Join Date
    Jun 2008
    Location
    Podunk
    Posts
    29,078
    Blog Entries
    15

    Default Re: Login Time

    Hi
    Run the following to see....

    Code:
    systemd-analyze blame
    systemd-analyze critical-chain
    It can be transient as well if some maintenance is running.
    Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
    SUSE SLE, openSUSE Leap/Tumbleweed (x86_64) | GNOME DE
    If you find this post helpful and are logged into the web interface,
    please show your appreciation and click on the star below... Thanks!

  3. #3
    Join Date
    Aug 2010
    Location
    Chicago suburbs
    Posts
    14,009
    Blog Entries
    3

    Default Re: Login Time

    I am not noticing this. For me, login to KDE takes about the same time as it did with Leap 15.1.

    But perhaps it depends on your display manager. I am currently using GDM to login.

    Yes, KDE/Plasma startup is slow. But once running, it seems very efficient. I'm willing to put up with a slow startup time in exchange for faster response once it has finished the startup.

    Hmm, the first login after upgrade to 15.2 is probably slow, because user configuration files (mostly in ".config" and ".local/share" have to be updated to the newer plasma version. And the cache probably has to be rebuilt.
    openSUSE Leap 15.2; KDE Plasma 5.18.5;

  4. #4
    Join Date
    Apr 2013
    Location
    Sydney, AU
    Posts
    245

    Default Re: Login Time

    [SOLVED]

    Startup finished in 2.712s (kernel) + 1.838s (initrd) + 7.455s (userspace) = 12.006s
    First i reduced the 'userspace' time by swapping out Wicked Network with Network Manager. That reduced system boot up to less than 8 seconds ....

    .... then i solved the long 'login time' by using a login-screen OTHER THAN "Breeze" or "Breeze for openSUSE" ... using either of the other two defaults, Elarun or Maldives OR installing a New Login Screen, reduced the login time to ~5 secs!!! Restating either of the Breeze Login Screens extends the login time to around 40 secs.

    Happy!!

    PS: I am now using "Sugar Dark"
    openSUSE Leap 15.2 | KDE Plasma 5.18.5 | Frameworks 5.71.0 | Qt 5.12.7 | Kernel 5.3.18-lp152.19-default | Procs 4 x i5-2500 CPU @ 3.3.GHz | 15.6 GiB RAM | 4 Monitors

  5. #5
    Join Date
    Jan 2017
    Location
    Nürnberg, Germany
    Posts
    276

    Default Re: Login Time

    Slightly off-topic, but those of you willing to experiment a little might be able to go a tad quicker from power-on to GUI+network (while learning stuff about Linux).
    I've just compiled the new mainline kernel 5.7.7 a few hours ago, with some tweaks. My result …

    Code:
    Startup finished in 505ms (kernel) + 423ms (userspace) = 929ms
    (Mind you, my 6 years old BIOS needs about a second to do its POST thing, then GRUB2 flickers its welcome message for a split-second despite me having set »set timeout_style=hidden« and »set timeout=0«; after that, my new kernel starts without any initrd — don't need one anymore — using above 929ms of time, and then the display manager auto-logins my user into KDE/Plasma, which itself needs about a second to set itself up. So it takes three to four seconds from pressing the power button to opening a GUI program. Still, not too shabby for a comparatively ancient Haswell i5.)

    Some of my userland tweaks (YMMV, take this with a few grains of salt):
    • one fast SATA SSD, and one ext4 root partition, properly aligned (no swap, and certainly no btrfs)
    • unthemed KDM for display manager; sadly way past its prime, but faster startup than any other DM (according to some tests I did in 2015)
    • no wicked, no NetworkManager; all my stuff is on IPv4-only static networking using systemd-networkd
    • disabled any eye-candy: no Plymouth, no animations, it's quiet and text-based until systemd launches KDM
    • used exim instead of postfix for a while (again, startup time), then nothing because of permanently emtpy mail queues
    • no cups (I only »print« to PDF), no NTP, no Samba, no unneeded stuff in general

    As for the kernel sources, I…
    • started playing with existing vs minimal vs automatic kernel configs (»make oldconfig« vs »make x86_64_defconfig« vs »make localyesconfig«); the automatic one ended up close enough to what I want
    • disabled all filesystems except for »ext4« (statically, necessary for booting) and »exfat« (as a module, just in case)
    • disabled IPv6, most crypto stuff, most server-class drivers; no Nouveau, no Intel iGPU stuff
    • disabled swap support (my 2 cents: if several gigabytes of RAM is not enough, all is lost)
    • disabled initrd support because I'm all for self-contained kernels
    • disabled all sorts of wireless technology: no infrared, no WiFi, no Bluetooth, no HAM radio
    • disabled excessive quota/monitoring/profiling stuff (might be fine for servers), unneeded for a desktop system
    • enabled SND_HDA_CODEC_REALTEK — despite Intel chipset, the sound chip vendor for my Asus board seems to be Realtek, and without kernel support it won't make a peep
    • enabled FW_LOADER=y, EXTRA_FIRMWARE_DIR="/lib/firmware" and most importantly for my old Core-i5: EXTRA_FIRMWARE="intel-ucode/06-3c-03" (without it, the kernel will complain)
    • set »root=/dev/sda1« as the kernel parameter (again, YMMV)
    • after compilation and installation, leave the kernel source as is; don't do a »make mrproper« too soon (to save storage space as I did), because subsequent installs (Nvidia drivers) may need those compiled kernel object files.

    Along the way, I learned so much about early booting with and without initial RAM disks. For example, dracut packs those microcode and firmware patches right into the initrd by default; without it, you have to give those patches to the kernel at compile-time as I did.

    Finally, I had to apply a tiny patch to the binary-blob-proprietary Nvidia driver, following Isaak Aleksandrov's instructions over at Gitlab. After that, your standard GTX card will play nicely with the 5.x kernel ABI like mine does. If you do Steam gaming with that Nvidia card, then please be sure to say »YES« to the 32-bit drivers when the Nvidia installer asks you. Oh well. You live, you learn.

    So I've learned stuff, I'm booting faster than ever, but I also have a nice and small footprint for backing up and virtualizing my system:

    Code:
    v:~ ▶ lsmod
    Module                  Size  Used by
    nvidia_drm             45056  5
    nvidia_modeset       1077248  13 nvidia_drm
    nvidia_uvm            946176  0
    snd_hda_codec_realtek    98304  1
    snd_hda_codec_generic    73728  2 snd_hda_codec_realtek
    nvidia              19972096  693 nvidia_uvm,nvidia_modeset
    snd_hda_intel          28672  3
    snd_intel_dspcfg       16384  1 snd_hda_intel
    snd_hda_codec          98304  3 snd_hda_codec_generic,snd_hda_intel,snd_hda_codec_realtek
    snd_hwdep              16384  1 snd_hda_codec
    snd_hda_core           61440  4 snd_hda_codec_generic,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek
    snd_pcm                90112  3 snd_hda_intel,snd_hda_codec,snd_hda_core
    snd_timer              32768  1 snd_pcm
    snd                    65536  12 snd_hda_codec_generic,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_timer,snd_pcm
    ipmi_devintf           20480  0
    ipmi_msghandler        53248  2 ipmi_devintf,nvidia
    v:~ ▶ l /boot/
    total 7008
    drwxr-xr-x  4 root root    4096 2020-07-02 14:59 ./
    drwxr-xr-x 20 root root    4096 2020-04-19 11:31 ../
    -rw-r--r--  1 root root    1725 2018-12-19 10:14 boot.readme
    -rw-r--r--  1 root root   85173 2020-07-02 13:15 config-5.7.7
    drwxr-xr-x  2 root root    4096 2019-10-31 14:04 dracut/
    drwxr-xr-x  6 root root    4096 2020-07-02 15:01 grub2/
    -rw-r--r--  1 root root     362 2020-07-02 13:35 sysctl.conf-5.7.7
    -rw-r--r--  1 root root 2648167 2020-07-02 13:22 System.map-5.7.7
    -rw-r--r--  1 root root 4411552 2020-07-02 13:22 vmlinuz-5.7.7
    v:~ ▶ du -sh /lib/modules/
    31M     /lib/modules/
    v:~ ▶ _
    There are many more things I've tried for fun over the years, but maybe this will be of use to some. Cheers!

  6. #6
    Join Date
    Jan 2014
    Location
    Erlangen
    Posts
    1,701
    Blog Entries
    1

    Default Re: Login Time

    Cold boot: Startup finished in 18.634s (firmware) + 3.611s (loader) + 914ms (kernel) + 1.885s (initrd) + 2.517s (userspace) = 27.563s

    http://mistelberger.net/erlangen.svg

    There is no need to cripple the system:

    Code:
    erlangen:~ # journalctl  -b -q --no-hostname -o short-monotonic --grep reached
    [    1.052469] systemd[1]: Reached target Local File Systems.
    [    1.054553] systemd[1]: Reached target Paths.
    [    1.056481] systemd[1]: Reached target Slices.
    [    1.058350] systemd[1]: Reached target Swap.
    [    1.060241] systemd[1]: Reached target Timers.
    [    1.068809] systemd[1]: Reached target Sockets.
    [    1.411392] systemd[1]: Reached target System Initialization.
    [    1.412683] systemd[1]: Reached target Basic System.
    [    2.373859] systemd[1]: Reached target Initrd Root Device.
    [    2.376427] systemd[1]: Reached target Remote File Systems (Pre).
    [    2.377237] systemd[1]: Reached target Remote File Systems.
    [    2.411676] systemd[1]: Reached target Initrd Root File System.
    [    2.556277] systemd[1]: Reached target Initrd File Systems.
    [    2.557080] systemd[1]: Reached target Initrd Default Target.
    [    2.641767] systemd[1]: Reached target Switch Root.
    [    3.193448] systemd[1]: Reached target Local Encrypted Volumes.
    [    3.200127] systemd[1]: Reached target Remote File Systems.
    [    3.201660] systemd[1]: Reached target Slices.
    [    3.203247] systemd[1]: Reached target System Time Set.
    [    3.277259] systemd[1]: Reached target Swap.
    [    3.305336] systemd[1]: Reached target Local File Systems (Pre).
    [    3.381096] systemd[1]: Reached target Local File Systems.
    [    3.614163] systemd[1]: Reached target System Initialization.
    [    3.631405] systemd[1]: Reached target Paths.
    [    3.639806] systemd[1]: Reached target Sockets.
    [    3.641782] systemd[1]: Reached target Basic System.
    [    3.981671] systemd[1]: Reached target Network.
    [    3.981806] systemd[1]: Reached target Network is Online.
    [    4.048316] systemd[1]: Reached target System Time Synchronized.
    [    4.075059] systemd[1]: Reached target Timers.
    [    4.226478] systemd[1]: Reached target Login Prompts.
    [    4.658145] systemd[1]: Reached target Multi-User System.
    [    4.831785] systemd[1]: Reached target Sound Card.
    [    5.299656] systemd[1]: Reached target Graphical Interface.
    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

  7. #7
    Join Date
    Jan 2017
    Location
    Nürnberg, Germany
    Posts
    276

    Default Re: Login Time

    Quote Originally Posted by karlmistelberger View Post
    There is no need to cripple the system:
    Sure, thats one word, »cripple«, and it's quite a harsh one.
    More in line with what I have in mind would be:
    • customize
    • harden
    • distill
    • finess
    • de-bloat
    • whittle down


    And that's without even using a thesaurus.

    Another slightly deflecting word is »need«.
    There's no »need«, for example, to use computers, or to install Linux, or openSUSE, to learn some kernel skills or to post in this forum. No need at all.
    But we do it anyway. Cheers!

  8. #8
    Join Date
    Jan 2017
    Location
    Nürnberg, Germany
    Posts
    276

    Default Re: Login Time

    Tiny addendum and correction: Above I mentioned incorrectly that Linux 5.7.7 was »the« mainline kernel. Actually, https://www.kernel.org/ declares version 5.7.7 as »stable«, and 5.8-rc3 spear-heads the mainline at the moment.

    Another nice detail:

    Quote Originally Posted by karlmistelberger View Post
    Code:
    erlangen:~ # journalctl  -b -q --no-hostname -o short-monotonic --grep reached
    [    1.052469] systemd[1]: Reached target Local File Systems.
    [    1.054553] systemd[1]: Reached target Paths.
    [    1.056481] systemd[1]: Reached target Slices.
    [    1.058350] systemd[1]: Reached target Swap.
    [    1.060241] systemd[1]: Reached target Timers.
    [    1.068809] systemd[1]: Reached target Sockets.
    [    1.411392] systemd[1]: Reached target System Initialization.
    [    1.412683] systemd[1]: Reached target Basic System.
    [    2.373859] systemd[1]: Reached target Initrd Root Device.
    [    2.376427] systemd[1]: Reached target Remote File Systems (Pre).
    [    2.377237] systemd[1]: Reached target Remote File Systems.
    [    2.411676] systemd[1]: Reached target Initrd Root File System.
    [    2.556277] systemd[1]: Reached target Initrd File Systems.
    [    2.557080] systemd[1]: Reached target Initrd Default Target.
    [    2.641767] systemd[1]: Reached target Switch Root.
    [    3.193448] systemd[1]: Reached target Local Encrypted Volumes.
    [    3.200127] systemd[1]: Reached target Remote File Systems.
    [    3.201660] systemd[1]: Reached target Slices.
    [    3.203247] systemd[1]: Reached target System Time Set.
    [    3.277259] systemd[1]: Reached target Swap.
    [    3.305336] systemd[1]: Reached target Local File Systems (Pre).
    [    3.381096] systemd[1]: Reached target Local File Systems.
    [    3.614163] systemd[1]: Reached target System Initialization.
    [    3.631405] systemd[1]: Reached target Paths.
    [    3.639806] systemd[1]: Reached target Sockets.
    [    3.641782] systemd[1]: Reached target Basic System.
    [    3.981671] systemd[1]: Reached target Network.
    [    3.981806] systemd[1]: Reached target Network is Online.
    [    4.048316] systemd[1]: Reached target System Time Synchronized.
    [    4.075059] systemd[1]: Reached target Timers.
    [    4.226478] systemd[1]: Reached target Login Prompts.
    [    4.658145] systemd[1]: Reached target Multi-User System.
    [    4.831785] systemd[1]: Reached target Sound Card.
    [    5.299656] systemd[1]: Reached target Graphical Interface.
    I didn't notice this command at first, but filtering for those »reached« messages is another nice way to get an overview of what happened during boot. Thank you, karlmistelberger, for adding this one to my toolbox.Here's what I'm looking at this morning:

    That boot chart has gotten quite slim, hasn't it?

    Coming back to the original topic of this thread (login time): filtering the journal for »reached« nicely illustrates that while my initial system-global init process (»systemd[1]« in the screenshot) finishes booting up in just under a second, the auto-login into KDE-Plasma has taken its child process »systemd[314]« another 1.4s. Arguably, this data reflects the startup+login time experienced by non-root users more closely than the 964ms that »systemd-analyze« is giving me. I'll keep that in mind for further testing.

    By the way: despite my (excessive?) experiments, my userspace still is 99% openSUSE (except for »non-free« VLC-codecs, proprietary Steam and equally proprietary Nvidia). This means I can still do everything with zypper, YaST, dracut etc I would normally do with any less modified openSUSE/SLED/SLES-based installation. It goes to show how stable the kernel ABI has become, having jumped from kernel 4.12 to the 5.7 just for giggles. Those kernel hackers around Linus Torvalds really don't break userspace much anymore.

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

    Default Re: Login Time

    Quote Originally Posted by unix111 View Post
    Coming back to the original topic of this thread (login time): filtering the journal for »reached« nicely illustrates that while my initial system-global init process (»systemd[1]« in the screenshot) finishes booting up in just under a second, the auto-login into KDE-Plasma has taken its child process »systemd[314]« another 1.4s. Arguably, this data reflects the startup+login time experienced by non-root users more closely than the 964ms that »systemd-analyze« is giving me. I'll keep that in mind for further testing.

    By the way: despite my (excessive?) experiments, my userspace still is 99% openSUSE (except for »non-free« VLC-codecs, proprietary Steam and equally proprietary Nvidia). This means I can still do everything with zypper, YaST, dracut etc I would normally do with any less modified openSUSE/SLED/SLES-based installation. It goes to show how stable the kernel ABI has become, having jumped from kernel 4.12 to the 5.7 just for giggles. Those kernel hackers around Linus Torvalds really don't break userspace much anymore.
    It's a minimal but usable and maintainable system. Forum posts are fixed content. Discussions in the forum mix with the content. Did you ever consider a structured wiki page? Wiki pages are readily updated and support discussions.
    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
    3,194

    Talking Re: Login Time

    Quote Originally Posted by griadooss View Post
    ... but from there i am unable to analyse what is taking a further 40 secs or so after supplying the password at the logon screen.
    You could have used “systemd-analyze blame | head” …

Page 1 of 2 12 LastLast

Tags for this Thread

Posting Permissions

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