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=041fe704

    Edit: Addendum, I am only starting with the speed dial - no page loading


  • Vivaldi Translator

    @Der_Pit
    Honestly I'm not sure what's happening there.

    But from my observation from all these time people reporting same behavior, they usually use modern Linux Desktop Environment, most KDE, it's rare to never see in GNOME 3 or Unity. And almost all the time that same people mentioned about keyring.
    I use none of them. I got memorable problem with Gnome-keyring & KDE keyring.

    For Windows, the usual culprits, all their Anti Something.



  • 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.


Log in to reply
 

Looks like your connection to Vivaldi Forum was lost, please wait while we try to reconnect.