Hi,
I'm experiencing the following issue:
after login (LightDM) I must wait +5 min until the desktop is displayed.
There's no waiting time when logging out and the login again, means the issue only occurs when starting or rebooting.
This is the relevant log /var/log/lightdm/lightdm.log:
root@pc5-desktop:/home/thomas# tail -n 50 /var/log/lightdm/lightdm.log
[+1311.40s] DEBUG: Session pid=2869: Running command /usr/sbin/lightdm-gtk-greeter
[+1311.40s] DEBUG: Creating shared data directory /var/lib/lightdm/data/lightdm
[+1311.40s] DEBUG: Session pid=2869: Logging to /var/log/lightdm/seat0-greeter.log
[+1312.12s] DEBUG: Activating VT 8
[+1312.12s] DEBUG: Locking login1 session 10
[+1312.13s] DEBUG: Activating login1 session c5
[+1312.14s] DEBUG: Seat seat0 changes active session to c5
[+1312.14s] DEBUG: Session c5 is already active
[+1313.14s] DEBUG: Greeter connected version=1.18.3 resettable=false
[+1315.67s] DEBUG: Greeter start authentication
[+1315.67s] DEBUG: Session pid=2908: Started with service 'lightdm', username '(null)'
[+1315.77s] DEBUG: Session pid=2908: Got 1 message(s) from PAM
[+1315.77s] DEBUG: Prompt greeter with 1 message(s)
[+1875.56s] DEBUG: Greeter start authentication for thomas
[+1875.56s] DEBUG: Session pid=2908: Sending SIGTERM
[+1875.56s] DEBUG: Seat seat0: Failed to work out session ID to mark
[+1875.56s] DEBUG: Session pid=3080: Started with service 'lightdm', username 'thomas'
[+1875.57s] DEBUG: Session pid=2908: Terminated with signal 15
[+1875.57s] DEBUG: Session: Failed during authentication
[+1875.57s] DEBUG: Seat seat0: Session stopped
[+1875.68s] DEBUG: Session pid=3080: Got 1 message(s) from PAM
[+1875.68s] DEBUG: Prompt greeter with 1 message(s)
[+1879.09s] DEBUG: Continue authentication
[+1879.17s] DEBUG: Session pid=3080: Authentication complete with return value 0: Success
[+1879.17s] DEBUG: Authenticate result for user thomas: Success
[+1879.18s] DEBUG: User thomas authorized
[+1879.21s] DEBUG: Greeter sets language de_DE.utf8
[+1879.30s] DEBUG: Greeter requests session lightdm-xsession
[+1879.30s] DEBUG: Seat seat0: Returning to existing user session thomas
[+1879.30s] DEBUG: Unlocking login1 session 10
[+1879.30s] DEBUG: Activating VT 7
[+1879.30s] WARNING: Error using VT_WAITACTIVE 7 on /dev/tty0: Interrupted system call
[+1879.30s] DEBUG: Seat seat0: Stopping greeter
[+1879.30s] DEBUG: Session pid=2869: Sending SIGTERM
[+1879.30s] DEBUG: Activating login1 session 10
[+1879.31s] DEBUG: Session pid=3080: Exited with return value 0
[+1879.31s] DEBUG: Seat seat0: Session stopped
[+1879.36s] DEBUG: Greeter closed communication channel
[+1879.36s] DEBUG: Session pid=2869: Exited with return value 0
[+1879.36s] DEBUG: Seat seat0: Session stopped
[+1879.36s] DEBUG: Seat seat0: Stopping display server, no sessions require it
[+1879.36s] DEBUG: Sending signal 15 to process 2855
[+1879.42s] DEBUG: Seat seat0 changes active session to
[+1879.50s] DEBUG: Process 2855 exited with return value 0
[+1879.50s] DEBUG: DisplayServer x-1: X server stopped
[+1879.50s] DEBUG: Releasing VT 8
[+1879.50s] DEBUG: DisplayServer x-1: Removing X server authority /var/run/lightdm/root/:1
[+1879.50s] DEBUG: Seat seat0: Display server stopped
[+1879.58s] DEBUG: Seat seat0 changes active session to 10
[+1879.58s] DEBUG: Session 10 is already active
How can I analyze the root cause further?
THX
Hi. You are not the only user struggling with this problem. Unfortunately the underlying issue is yet to be found. Personally I would advise changing kernel. My expirence shows that kernel 4.16 from Debian repo is free from this issue. Same goes for kernel 4.18 from sparky unstable repo.
post linux kernel (inxi works well) and post first few lines of
"systemd-analyze blame"
very well could be the kernel version.
Linux Kernel:
thomas@pc5-desktop:~$ sudo inxi -S
System: Host: pc5-desktop Kernel: 4.17.0-2-amd64 x86_64 bits: 64 Console: tty 0
Distro: SparkyLinux 5 (Nibiru)
thomas@pc5-desktop:~$ sudo systemd-analyze blame
3.398s NetworkManager-wait-online.service
3.345s dev-sda2.device
1.919s exim4.service
1.653s systemd-hwdb-update.service
1.193s udisks2.service
1.043s user@109.service
860ms networking.service
848ms ModemManager.service
728ms keyboard-setup.service
598ms systemd-journald.service
525ms avahi-daemon.service
519ms systemd-udev-trigger.service
After reproducing the issue log /var/log/lightdm/lightdm.log is displaying this info that confirms that waiting time:
thomas@pc5-desktop:~$ sudo tail -f /var/log/lightdm/lightdm.log
[+53.76s] DEBUG: Seat seat0: Stopping greeter; display server will be re-used for user session
[+53.76s] DEBUG: Session pid=732: Sending SIGTERM
[+53.79s] DEBUG: Greeter closed communication channel
[+53.80s] DEBUG: Session pid=732: Exited with return value 0
[+53.80s] DEBUG: Seat seat0: Session stopped
[+53.80s] DEBUG: Seat seat0: Greeter stopped, running session
[+53.80s] DEBUG: Registering session with bus path /org/freedesktop/DisplayManager/Session0
[+53.81s] DEBUG: Session pid=1311: Running command /etc/X11/Xsession default
[+53.81s] DEBUG: Creating shared data directory /var/lib/lightdm/data/manfred
[+53.81s] DEBUG: Session pid=1311: Logging to .xsession-errors
[+148.87s] DEBUG: Activating VT 7
[+148.87s] DEBUG: Activating login1 session 4
[+148.87s] DEBUG: Seat seat0 changes active session to
[+148.87s] DEBUG: Seat seat0 changes active session to 4
[+148.87s] DEBUG: Session 4 is already active
[+773.85s] DEBUG: Seat seat0: Locking
[+773.85s] DEBUG: Seat seat0: Creating greeter session
[+773.85s] DEBUG: Seat seat0: Creating display server of type x
[+773.85s] DEBUG: Using VT 8
[+773.85s] DEBUG: Seat seat0: Starting local X display on VT 8
[+773.85s] DEBUG: DisplayServer x-1: Logging to /var/log/lightdm/x-1.log
[+773.85s] DEBUG: DisplayServer x-1: Writing X server authority to /var/run/lightdm/root/:1
[+773.85s] DEBUG: DisplayServer x-1: Launching X Server
[+773.85s] DEBUG: Launching process 1889: /usr/bin/X :1 -seat seat0 -auth /var/run/lightdm/root/:1 -nolisten tcp vt8 -novtswitch
[+773.85s] DEBUG: DisplayServer x-1: Waiting for ready signal from X server :1
[+774.06s] DEBUG: Seat seat0 changes active session to
[+775.01s] DEBUG: Got signal 10 from process 1889
[+775.01s] DEBUG: DisplayServer x-1: Got signal from X server :1
[+775.01s] DEBUG: DisplayServer x-1: Connecting to XServer :1
[+775.01s] DEBUG: Seat seat0: Display server ready, starting session authentication
[+775.02s] DEBUG: Session pid=1902: Started with service 'lightdm-greeter', username 'lightdm'
[+775.12s] DEBUG: Session pid=1902: Authentication complete with return value 0: Success
[+775.12s] DEBUG: Seat seat0: Session authenticated, running command
[+775.12s] DEBUG: Session pid=1902: Running command /usr/sbin/lightdm-gtk-greeter
[+775.12s] DEBUG: Creating shared data directory /var/lib/lightdm/data/lightdm
[+775.12s] DEBUG: Session pid=1902: Logging to /var/log/lightdm/seat0-greeter.log
[+775.72s] DEBUG: Activating VT 8
[+775.72s] DEBUG: Locking login1 session 4
[+775.73s] DEBUG: Activating login1 session c2
[+775.74s] DEBUG: Seat seat0 changes active session to c2
[+775.74s] DEBUG: Session c2 is already active
[+776.45s] DEBUG: Greeter connected version=1.18.3 resettable=false
[+778.80s] DEBUG: Greeter start authentication
[+778.80s] DEBUG: Session pid=1941: Started with service 'lightdm', username '(null)'
[+778.87s] DEBUG: Session pid=1941: Got 1 message(s) from PAM
[+778.87s] DEBUG: Prompt greeter with 1 message(s)
Installing another kernel is not fixing the isse, means with this kernel 4.16.0-2-amd64 x86_64 from Debian Sid the same waittime is noticed:
thomas@pc5-desktop:~$ inxi -S
System: Host: pc5-desktop Kernel: 4.16.0-2-amd64 x86_64 bits: 64 Desktop: N/A Distro: SparkyLinux 5 (Nibiru)
thomas@pc5-desktop:~$ sudo tail -f /var/log/lightdm/lightdm.log
[+41.96s] DEBUG: Seat seat0: Stopping greeter; display server will be re-used for user session
[+41.96s] DEBUG: Session pid=721: Sending SIGTERM
[+41.99s] DEBUG: Greeter closed communication channel
[+41.99s] DEBUG: Session pid=721: Exited with return value 0
[+41.99s] DEBUG: Seat seat0: Session stopped
[+41.99s] DEBUG: Seat seat0: Greeter stopped, running session
[+41.99s] DEBUG: Registering session with bus path /org/freedesktop/DisplayManager/Session0
[+42.01s] DEBUG: Session pid=1278: Running command /etc/X11/Xsession default
[+42.01s] DEBUG: Creating shared data directory /var/lib/lightdm/data/manfred
[+42.01s] DEBUG: Session pid=1278: Logging to .xsession-errors
[+301.44s] DEBUG: Activating VT 7
[+301.44s] DEBUG: Activating login1 session 4
[+301.45s] DEBUG: Seat seat0 changes active session to
[+301.45s] DEBUG: Seat seat0 changes active session to 4
[+301.45s] DEBUG: Session 4 is already active
Code marked up and lightdm log attached, that helps a lot.
I don't have xfce, I use sddm. A quick check of the changelog of xfce 4.12, no major changes, just a lot of bug fixes. Debian BTS for lightdm, nothing about lightdm getting hung up at start. A quick check of sddm and xfce4, no blogs or posts of people liking sddm more than lightdm, just a few people with problems. So my opinion it that it is not worthwhile to change form lightdm to sddm to see if that cures. I would say keep it with lightdm unless competent people say sddm has worked or cured promblems with XFCE4 for them..
You could check the Debian forums, but they discourage even Debian posting problems with testing. Maybe watch on irc the XFCE channel and debian-xfce is there is one. You can post on XFCE irc. Pastebin your lightdm.log.
Only other thing that comes to mind is do you have more than one DE that uses the same ~/home/blah Sometimes the "dot files .config/ .local/ etc. can clash.
peace out mark
I am having this problem, too, and am not using xfce4, but rather openbox:
$ sudo tail -f /var/log/lightdm/lightdm.log
[sudo] password for me:
[+36.15s] DEBUG: Seat seat0 changes active session to 2
[+36.15s] DEBUG: Session 2 is already active
[+791.34s] DEBUG: Session pid=1425: Terminated with signal 1
[+791.34s] DEBUG: Seat seat0: Session stopped
[+791.34s] DEBUG: Seat seat0: Stopping display server, no sessions require it
[+791.34s] DEBUG: Sending signal 15 to process 1215
[+791.35s] DEBUG: Got signal 15 from process 1
[+791.35s] DEBUG: Caught Terminated signal, shutting down
[+791.35s] DEBUG: Stopping display manager
[+791.35s] DEBUG: Seat seat0: Stopping
Motivated by the previous discussion, I did some experimenting relative to display managers. I noticed that I had both lightdm and slim installed with slim the default. I tried every combination of installed, removed, defaulted, etc between these two display managers with the same result - a long delay (measured in minutes) after putting in user and password. So I removed both slim and lightdm, and installed xdm. Bingo! Almost instant (like 2 or 3 seconds) desktop after login. So I'm an xdm fan now.
Upgrading to kernel 4.17 appears to have created chaos in login. A second computer has experienced with lightdm and slim long (like 5 minutes) delay after log-in. This time changing display manager to xdm resulted in a login screen staying up about 1 second, not long enough to type user name and password. So I tried lxdm and all went well. What's happening?
By the way, to install lxdm, use the "no-install-recommends" command to avoid getting an lxde desktop installed as well:
sudo apt-get install --no-install-recommends lxdm
Well if none of the "..." tried and true DM's are not working in XFCE4, I toss out this option.
Debian change logs
lxdm 2016 and a Feb 2018 minor update by non-maintainer
slim
april and may 2017
xdm
1 .11-2 1.11-3 Dec 2015
1.11-1 2011
Soo - if some brave soul wants to try out sddm in xfce that might be interesting. sddm a clean write of a desktop manager made to not conflict with systemd (but has problems with wayland). It is supposed to neutral to all desktop environments, not just a dm for kde (and some lxqt's)
https://github.com/sddm/sddm
https://wiki.archlinux.org/index.php/SDDM#Long_load_time_before_SDDM_shows_the_greeter
https://metadata.ftp-master.debian.org/changelogs/main/s/sddm/sddm_0.18.0-1_changelog
peace out.
The problem is not any session manager related itself.
Found a solution, simply run:
sudo apt purge libpam-gnome-keyring
sudo reboot
and let me know does it help, please.
Quote from: pavroo on September 06, 2018, 01:24:13 PM
The problem is not any session manager related itself.
Found a solution, simply run:
sudo apt purge libpam-gnome-keyring
sudo reboot
and let me know does it help, please.
This solution solved my issue.
THX!!!
Quote from: pavroo on September 06, 2018, 01:24:13 PM
The problem is not any session manager related itself.
Found a solution, simply run:
sudo apt purge libpam-gnome-keyring
sudo reboot
and let me know does it help, please.
There is an extreme delay in the LXQt DE being displayed also. However, I have Sparky LXQt in a VirtualBox VM, if that makes any difference. The above commands have no effect in LXQt. Is there an equivalent solution for Qt-based systems?
Yes, try it running with Sparky kernel, works ok.
Sparky 5 = Deian testing.
Debian 4.18 kernel in virtualbox comes up fast
i3 cpu, 8gb mem.
libpam-gnome-keyring automatically installed on LXQT - has been for years.
Several year old lxqt install of sparky - debian kernel 4.18
atom cpu 1 gb memory, about a minute to spin up.
Never been a problem.
As always I suggest looking for the slowdown via "systemd-analyze" especially "systemd-analyze blame" search forum and you will find more or look at digitalocean for systemd tutorials.
For 3 year old lxqt install that started in testing and is now in stable debian (backports enabled) it looks like
paxmark@raunes:~$ systemd-analyze blame
5.627s connman-wait-online.service
4.511s lvm2-monitor.service
4.059s libvirtd.service
3.713s apparmor.service
2.886s dev-mapper-raunes\x2d\x2dvg\x2droot.device
1.853s gpm.service
1.773s systemd-journal-flush.service
1.760s networking.service
1.442s lightdm.service
1.437s keyboard-setup.service
1.408s upower.service
1.285s systemd-udevd.service
1.273s systemd-fsck@dev-disk-by\x2duuid-4117\x2d423C.service
1.198s user@1000.service
1.144s lm-sensors.servi
and some more blah.
I confess, I do like lxqt, have for years. peace out.
Paxmark...good advice, but I have already done all that. Thanks to the good advice in other threads on this forum, I got systemd-analyze time and systemd-analyze blame to indicate a 6 second boot to desktop (inclusive of kernel AND userspace). However, despite the systemd-analyze results, only the wallpaper shows for approximately 1-3 minutes after lightdm login. It seems to vary in time, but even the fastest desktop appearance is excruciatingly SLOW...
However, pavroos suggestion to install the Sparky kernel and boot with that has resolved the issue! Good call pavroo!
While I consider this resolved (at least for me), I'm wondering why Sparky doesn't install with it's own Sparky kernel? Before I followed pavroos advice, I verified with uname -a that Sparky was indeed booting with a Debian 4.18.0 kernel. I was just surprised that the default install kernel is Debians, rather than Sparky. I'm an Lubuntu refugee, looking for a new distro with rolling capability, so optional kernel choices are kind of a new thing for me, other than low-latency or liquorix choices. Educate me please!
With all that said, I'd like to take a moment and say THANKS to pavroo and other Sparky devs for a FANTASTIC offering of LXQt, which I'm REALLY liking...A LOT! Although my daily driver is Lubuntu, I provide tech support and administer NUMEROUS machines for friends & family. They use whatever I use, but I'm truly tired of re-installing approximately 20+ fixed release distros every 3+ years; so I'm looking to go rolling release, but stay in the familiar Debian family, if at all possible. And while I absolutely LOVE the LXDE environment, I see the handwriting on the wall and recognize that LXQt is the future; the faster the uptake of LXQt, the faster the demise (or gtk3 fork) of LXDE. And with Lubuntu making the switch to LXQt in the soon-to-be-release 18.10 offering, I think there will be a huge influx of LXQt users in the next 2-20 months.
So I'm shopping for a new LXQt-based rolling-release distro that I can port my heavily customized LXDE-OpenBox-FluxBox-PekWM desktop to. And the fact that Sparky is Debian-based is a bonus, and the polish of the LXQt desktop is a bonus, but the apparent responsiveness and troubleshooting ability of an active and thriving community with devs in the forum amongst us is a HUGE consideration! I can't seem to say enough good things about what I see here in the Sparky community. KUDOS on a job well-done! I've been looking and experimenting with numerous distros for almost 2 years. But now I'm thinking that perhaps I might have found MY perfect choice of distro? I'll certainly be sticking around for awhile! 8)
So - pavroo brewed a better 4.18 than Debian for some purposes. That is a great job. 4.18 has been biting a few people in the butt for various issues from what I have seen in Siduction, a good place to lurk for those of us in testing- Sparky 5.
https://github.com/orgs/lxqt/people are always interested in help.
#lxqt on OFTC for user support for quick fixes.
Fluxbox additions nice. You do know that you are much more accomplished than I in Linux. I just keep plugging systemd and command line fixes I know by heart and remember old mistakes I made (running out of space on root, etc.)
Quote from: paxmark1 on September 21, 2018, 06:33:29 PM
So - pavroo brewed a better 4.18 than Debian for some purposes. That is a great job. 4.18 has been biting a few people in the butt for various issues from what I have seen in Siduction, a good place to lurk for those of us in testing- Sparky 5.
https://github.com/orgs/lxqt/people are always interested in help.
#lxqt on OFTC for user support for quick fixes.
Fluxbox additions nice. You do know that you are much more accomplished than I in Linux. I just keep plugging systemd and command line fixes I know by heart and remember old mistakes I made (running out of space on root, etc.)
Haha...you would be quite mistaken. I usually don't have a clue what I'm doing, but I'm fairly good at the logical isolation of troubleshooting components, and I can google pretty well, and I have a knack for finding people like pavroo who really DO know what they're doing! As for me, I'm just a persistently stubborn hacker-type who keeps plugging away until I get the desired result, or until I find a workaround while someone else figures it out. LOL!
I'm quite enamored with LXQt and see the long-term implications, but the lack of documentation and a knowledge base is quite frustrating. I'm hoping that an influx of LXQt users will spurn more LXQt development, which will in turn improve the documentation. I'll contribute what I can, where I can, but right now my head is swimming with LXQt issues. I can hack an LXDE desktop like nobody's business, then try to apply that to LXQt only to find that feature "hasn't been implemented yet." Grrrr.... I keep telling myself to be patient and it will mature, much like LXDE did.
In the meantime, good advice regarding the Siduction forums. I really like Siduction LXQT, but even Sid devs recommend against using Siduction for production machines. But that's what lead me to Sparky, and it's looking more and more like Sparky is a better long-term fit for me! But I'll continue to watch SID (Still In Development!), as whatever is in Sid today will likely filter to Sparky tomorrow.
I see your and pavroos posts all over this forum, helping others with issue. I hope to contribute what I can, when I can, according to my ability; at least as much if not more than I require. I hope...
The same problem has occured to all my last installations.
The problem: black screen after login, even if autologin is set, a few minutes of waiting untill the desktop is shown. The only bypass was to press random keys or to move the mouse pointer.
PC 1: Sparky LXQT (testing) installed in my 32bit laptop (ssd, ddr2). It started in the summer of 2018. It had the 4.16 or 4.17 kernel at that time. It is always fully updated. I still have to wait some minutes untill it shows the desktop.
PC 2 (triple installation): Sparky LXQT (testing) installed in my 32bit desktop (ssd, ddr2). It was installed one month ago from sparkylinux-5.6-i686-pae-minimalcli.iso. It was always fully updated. I always had to wait some minutes untill it showed the desktop. I deleted it yesterday. I reinstalled it from the latest 5.6.1minimalcli.iso (testing) but with the MATE desktop this time. No luck. The same problem. I reinstalled it today, again from the same 5.6.1minimalcli.iso (testing) but with Cinnamon. The same problem again, The only difference in Cinnamon is that the screen is blue instead of black, as if it is almost ready to show the desktop.
I am thinking of abandoning the use of testing isos, in favor of the stable isos, if they prove that they do not suffer from the same problem. I am frustrated.
Basic question. Have you tried Sparky kernel?
uname -r gives: 4.20.0-sparky-686-pae (in cinnamon testing 32bit)
Is this a sparky kernel? I have not installed a sparky kernel.
I wish I am wrong.
inxi gives:
CPU: Single Core Intel Pentium 4 (-MT-) speed/min/max: 2800/2800/3400 MHz
Kernel: 4.20.0-sparky-686-pae i686 Up: 6m Mem: 590.9/1945.6 MiB (30.4%)
Storage: 111.79 GiB (3.3% used) Procs: 162 Shell: bash 4.4.23 inxi: 3.0.29
Quote from: pavroo on September 06, 2018, 01:24:13 PM
The problem is not any session manager related itself.
Found a solution, simply run:
sudo apt purge libpam-gnome-keyring
sudo reboot
and let me know does it help, please.
This solution, provided by Pavroo, helped original poster with his problem. Have you tried it too?
Hello everyone,
i had the same problem with Manjaro KDE.
My solution was
sudo apt-get install haveged
and
sudo systemctl enable haveged.service
sudo systemctl start haveged.service
Maybe it will help you too.
Quote from: Bluewater on January 04, 2019, 10:42:23 AM
My solution was
sudo apt-get install haveged
and
sudo systemctl enable haveged.service
sudo systemctl start haveged.service
I must admit It might be worth a try.
The command "sudo apt purge libpam-gnome-keyring" did nothing to LXQT , MATE and Cinnamon installations of mine, because the package was not installed. If you check the minimalcli.isos package list, you will not find it there.
After checking, via aptus > install sparky kernel, whether I could install sparky kernel, I saw something like "It is allready installed" in both lxqt and cinnamon. I am not sure if I had checked it in Mate or not before I erased the hard disk.
I will try the haveged.service now and I will post again.
Success!
The absolute solution to the "taking too long after login screen to display the desktop" problem is:
sudo apt-get install haveged
sudo systemctl enable haveged.service
sudo systemctl start haveged.service
It worked perfectly! Both LXQT and Cinnamon desktop loaded the desktop immediately after login!
Thank you very much!
In addition it is proven that
sudo systemctl is a great tool that reveals much more information than "systemd-analyze". A GUI for systemctl would add even more value to it.
What is interesting is that my Sparky LXQT 32bit uses 235mb of memory when started (old intel laptop), while Sparky Cinnamon 32 bit uses only 290mb of memory when started (old intel desktop). I had never seen something so low from Cinnamon. This proves the usefulness of installing from sparky minimalcli iso.
Great solution, great linux distribution, great forum!
I did a quick read on "man haveged" maybe it has something to do with
https://daniel-lange.com/archives/152-Openssh-taking-minutes-to-become-available,-booting-takes-half-an-hour-...-because-your-server-waits-for-a-few-bytes-of-randomness.html ## which comes via Planet Debian.
towards the end of the web page
QuoteHaveged
apt install haveged
Haveged is a user-space daemon that gathers entropy though the timing jitter any CPU has. It will only run "late" in boot but may still get your openssh back online within seconds and not minutes.
I'm glad I finally read this topic. I'm using MATE, and I've been seeing
some delay (like 5 to 30 seconds) before the desktop is displayed -- and if I move the mouse, the desktop pops up promptly. Mouse motion is probably seeding the random number generator.
Also I've been wondering about the random number generator. I've got an alarm clock script that uses 'shuf' to pick a random music file to play, and it seems like I've been hearing a lot of the same "random" tunes recently. I haven't done a controlled test, so it might just be my misperception -- but it would be weird if both issues had the same cause.
Quote from: paxmark1 on January 04, 2019, 05:30:27 PM
https://daniel-lange.com/archives/152-Openssh-taking-minutes-to-become-available,-booting-takes-half-an-hour-...-because-your-server-waits-for-a-few-bytes-of-randomness.html
Thanks for that link. I tried one of his other suggestions in place of '
haveged':
QuoteKernel boot parameter
From kernel 4.19 (Debian Buster currently runs 4.18 [Update: but will be getting 4.19 before release according to Ben via Mika]) you can set RANDOM_TRUST_CPU at compile time or random.trust_cpu=on on the kernel command line. This will make Intel / AMD system trust RDRAND and fill the entropy pool with it.
This tells Linux to trust the CPU's built-in random number generator. How to set it up:
- sudo nano /etc/default/grub
- Find a line that looks like this:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash resume=UUID=..."
and change it to:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash random.trust_cpu=on resume=UUID=..."
and save the file (ctrl-X if you're using nano). - sudo update-grub
- Restart the computer.
Maybe it worked. I didn't see a delay before the desktop appeared. (Tomorrow morning I'll see what random tune wakes me up!)