First start after boot takes LONG
-
Hi,
since several versions (I'm using vivaldi-snapshot), the start time of the browser after a reboot (and only then) is ridiculous.
I start it via autostart (Plasma5) and directly get the kwallet access request. But until the browser window then appears it takes some 30s or more.
Again, this is only after a reboot. If I log out and then in again, the browser window pops up faster than I can fill out the kwallet password...
So no, it's not because of a slow machine (anyhow there is no CPU load during the startup), vivaldi (or something else) is doing something different after a reboot. I also somehow doubt that it is disk caching, the installation is on an SSD. Any idea what the reason might be?
This is on linux (openSUSE), but I have seen a similar complaint for Windows on reddit:
https://www.reddit.com/r/vivaldibrowser/comments/4jd5lp/vivaldi_takes_a_very_long_time_to_open_the_first/?st=j0ays2o5&sh=041fe704Edit: Addendum, I am only starting with the speed dial - no page loading
-
Ah, that's an interesting remark, though I think the keyring access does not interrupt the browser start, but is done in parallel/background: I often have the browser window cover the kwallet password dialog, so it doesn't need the acces to continue.
Another thing that came to my mind is DNS resolving. If starting up needs tons of those (from extensions? Or Vivaldi itself?) and some servers are slow that might take time. On the second / consecutive start those would be in the nscd cache and resolve immediately....
I'll try to think of some ways to track this somehow. -
I've got the same problem. Using Solus with Budgie as desktop environment.
I don't think it has anything to do with modern DE or not as I also have this problem in i3, which is very, very lightweight. Although it does launch faster in i3 than in Budgie, but still longer than it should.
My laptop has decent specs (4GB RAM, fast SSD, etc. and is from 2016) so the specs aren't the problem.
-
So my guess probably was not too bad. I switched off the autostart, and ran vivaldi using strace. What I could see was a lot of polling timeouts like
poll([{fd=11, events=POLLIN}, {fd=12, events=POLLIN}, {fd=13, events=POLLIN}], 3, 0) = 0 (Timeout)
where the file descriptors belong to an X socket (/tmp/.X11-unix/X0) and auth file (/tmp/xauth-1000-_0).
A second run started fast, as always.
As a try, I restarted nscd - and the huge delay was there again!Not that I'm much smarter now, I don't really know what to do with that info, but probably it's not vivaldis fault here....
-
Uh, I think I solved it, or rather found my error. nscd is involved, but not the culprit. As I often switch networks I disabled setting hostname from DHCP, but instead use a fixed /etc/HOSTNAME set to "woodstock.pitnet".
This is not resolvable of course, and the entry I had in my /etc/hosts got accidentally deleted during some reconfiguration. So anything that refered to my local hostname and tried to resolve the IP address ran into DNS timeouts :o
Adding an /etc/hosts entry again removed the delay. -