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.

Hi
Run the following to see…


systemd-analyze blame
systemd-analyze critical-chain

It can be transient as well if some maintenance is running.

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.

[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”

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 …

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:

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!

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:

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.

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. :wink:

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!

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:

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:

SUSE Paste 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.

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.

You could have used “systemd-analyze blame | head” …

Ooops – missed Malcom’s post below …

Definitely approaching minimal in some areas, yeah. On the other hand, I’ve grown really accustomed to the numerous bells and whistles KDE-Plasma/KWin/Dolphin provide.
It’s nice, though, to be able to try out new kernels or drivers as easily as any other repo-, RPM- or tarball-based package now, once everything is in place and some working step-by-step recipes have been established.
So I’d add »educational« to the ongoing process of making my openSUSE installation truly mine. (In the past I repeatedly tried a similar process with OS X/macOS, and with MS Windows at work, but nothing beats Linux here.)

Yes, I have been considering wiki articles (did a few edits on Wikipedia), or a blog, or a Gitlab-/Github-based collection of markdown documents.
After all, many of the things many of us try out we did first read on blogs, wikis (for example, Arch has an impressive wiki), Github and so on.

On the other hand, there is considerably less discussion happening there, at least in my experience, compared to mailing lists or forums like Usenet (now essentially Google Groups, oh well), or StackOverflow, ServerFault, Reddit or these fine openSUSE forums. I really do like the forum-style direct exchange of ideas.

Another thought: the more effort one puts into editing blogs or wiki articles, the less motivation one might have left for answering forum posts.

Systemd erroneously unmounted partitions already mounted through /etc/fstab. That started lengthy discussions:

Summarizing doesn’t do any harm:

I wholeheartedly agree with this. Let’s see what there is to be tried out in the near future.
Something on Gitlab, something Pandoc-based, maybe.