Is vivaldi starting to start more slowly to anyone here ?

seth · 2025-10-04 19:43:29

So the first line after the stall is actually

[7:7:1004/124833.758619:ERROR:chromium/dbus/object_proxy.cc:573] Failed to call method: org.freedesktop.systemd1.Manager.StartTransientUnit: object_path= /org/freedesktop/systemd1: org.freedesktop.DBus.Error.InvalidArgs: Process 7 is a kernel thread, refusing.

Are you currently running a notification daemon?

notify-send foo

Does firejail vivaldi start faster if such daemon is already running?

Succulent of your garden · 2025-10-04 19:58:41

No, I'm not running a notification daemon. Should I use Dunst in my case for Dwm ? or you suggest notify-send ?

Also I made the complete trimming of the SSD, now I'm starting to see how to do the dd benchmark for the other post, but it seems that the system is a little bit more faster, just a little, I mean mili or nano seconds degree. So the vivaldi issue still persists. I saw that other applications are now just running fine. Sometimes startx take like a second or 2 to load, but after that everything just works fast as I expected, but not vivaldi, that's the current state of the art of my machine. So by deleting files and trimming seems to made an improvement. Also the startx slow start only had happen once in like one or two weeks.

Today I'm taking care of this machine to troubleshoot these issues, and I was deleting orphan packages, seeing services available and stopping things like docker to get how much my system is using of ram by being idle. I notice that without using WM I'm using 1.4 GB, I'm ussing networkmanager with iwd. Do you consider that amount of ram fine for my computer in idle using Arch Linux ? I mean it seems that the most consuming thing according to top is systemd, but I don't think that systemd only can get until 1.4GB, so do you think if I debloat NM + iwd I could get lower right ? Do you consider that amount of ram strange for this kind of minimal setup ? I'm currently not logging everything with using tools like prometheus, I'm just getting that 1.4 GB of ram in idle like the most normal pc a Linux user can have, mnimium ammount of services and applications as possible. Do you think is fine that amount for Arch Linux ?

EDIT:

Also if you can help me with this if you can I'll be more than happy: https://bbs.archlinux.org/viewtopic.php?id=308590

Last edited by Succulent of your garden (2025-10-04 20:11:49)

seth · 2025-10-04 20:19:12

notify-send will just send a notification, install and run dunst before trying to firejail vivaldi

Succulent of your garden · 2025-10-04 20:43:30

I installed dunst, copied the /etc/dunst/dunstrc to my dot files in ~.config/dunst and added dunst & before dwm in my .xinitrc, nothing happens, it's the same I don't think this is necessary because of the green box in the arch wiki: https://wiki.archlinux.org/title/Dunst#Troubleshooting

So do you think the 1.4 GB of ram in idle are okey for Arch ? I mean in my alpine containers I could get it into 512 MB .

seth · 2025-10-05 07:22:13

When you're now running "notify-send foo", do you get a notification? Does "firejail vivaldi" still stall before

[7:7:1004/124833.758619:ERROR:chromium/dbus/object_proxy.cc:573] Failed to call method: org.freedesktop.systemd1.Manager.StartTransientUnit: object_path= /org/freedesktop/systemd1: org.freedesktop.DBus.Error.InvalidArgs: Process 7 is a kernel thread, refusing.

You could run dbus-monitor (session/system) to figure what it's trying to call and trigger there.

LuxFerre · 2025-10-05 10:02:29

Succulent of your garden wrote:

So do you think the 1.4 GB of ram in idle are okey for Arch ? I mean in my alpine containers I could get it into 512 MB .

I'm close do 2gb simply booting KDE (with my services etc, before opening apps), an arch with 'nothing' would probably be under 512mb (given that 512 is the minimum recommended by the wiki). NetworkManager can be relatively heavy, you could try a different solution but unless you really need the ram it might just be a waste of time...

Last edited by LuxFerre (2025-10-05 10:03:01)

Succulent of your garden · 2025-10-05 12:06:01

seth wrote:

When you're now running "notify-send foo", do you get a notification? Does "firejail vivaldi" still stall before

I lacked libnotify yesterday, I install it today and now I can see the notify-send foo in my screen. But vivaldi still start slow, and doesn't show nothing in the notification daemon.

seth wrote:

[7:7:1004/124833.758619:ERROR:chromium/dbus/object_proxy.cc:573] Failed to call method: org.freedesktop.systemd1.Manager.StartTransientUnit: object_path= /org/freedesktop/systemd1: org.freedesktop.DBus.Error.InvalidArgs: Process 7 is a kernel thread, refusing.

This is error doesn't happen when I launch vivaldi without firejail, it seems this is the main issue.

seth wrote:

You could run dbus-monitor (session/system) to figure what it's trying to call and trigger there.

Can you help me in how to make that ? Probably I'm going show something very noob for you if I made it by myself

LuxFerre wrote:

I'm close do 2gb simply booting KDE (with my services etc, before opening apps), an arch with 'nothing' would probably be under 512mb (given that 512 is the minimum recommended by the wiki). NetworkManager can be relatively heavy, you could try a different solution but unless you really need the ram it might just be a waste of time...

I was making the mistake of treating gibibytes to gigabytes in free command LoL, Now I can see that my system is probably not using to much ram, it seems a lot is in buff/cache, but some things doesn't make sense to me, If I discount the used to buff/cache I get 404 megabytes being in used, which probably is not possible in Arch. Yesterday I was reading this post https://bbs.archlinux.org/viewtopic.php?id=302537 were many were big braining about how free makes the ram approximation. The most strange thing is that is showing that in total I have more than i really have, that's weird, please can someone explain me why is this happening ? I don't use swap so IDK why is showing that, you can check my free command in the link below ^^

https://paste.ofcode.org/LdQMAgCi4CsLGwCKGQnRMB

EDIT: machine epsilon maybe ? https://en.wikipedia.org/wiki/Machine_epsilon not sure, how can 64 bits can be so trash in making aproximations ? LoL

Last edited by Succulent of your garden (2025-10-05 12:07:55)

seth · 2025-10-05 12:55:45

Can you help me in how to make that ?

dbus-monitor --session
dbus-monitor --system

Either will sniff the session and system bus traffic and print it.
Running that and then attempting to start vivaldi in a second shell will tell you if and what it calls (on which bus)

big braining about how free makes the ram approximation

cat /proc/meminfo

All higher level abstractions (free, *top, …) will implicitly define what's "free" what's ok for relative measuring ("is it now more?") but no absolute ("how much?") nor do you get a reliable information of what that actually means (there was a change in the a a tool calculated "free" memory and two weeks of "my arch system loses RAM" because of that )

Succulent of your garden · 2025-10-11 12:58:38

Time to big brain more: here are my logs for vivaldi opening using dbus-monitor --session

https://paste.ofcode.org/wwxPTf37ZBWM5XsUmdcChC

seth wrote:

All higher level abstractions (free, *top, …) will implicitly define what's "free" what's ok for relative measuring ("is it now more?") but no absolute ("how much?") nor do you get a reliable information of what that actually means (there was a change in the a a tool calculated "free" memory and two weeks of "my arch system loses RAM" because of that roll)

Thanks! I'm going to create a script with a regex that shows me the real memory being in used with cat /proc/meminfo ^^ . Probably I could use some dunst notifcation on it

seth · 2025-10-11 13:49:38

method call time=1760187143.641512 sender=:1.42 -> destination=org.freedesktop.systemd1 serial=5 path=/org/freedesktop/systemd1; interface=org.freedesktop.systemd1.Manager; member=StartTransientUnit
   string "app-com.vivaldi.Vivaldi-7.scope"
   string "replace"
   array [
      struct {
         string "PIDs"
         variant             array [
               uint32 7
            ]
      }
   ]
   array [
   ]

Does "interface=org.freedesktop.systemd1.Manager; member=StartTransientUnit" also show up in the non-firejail case?

Succulent of your garden · 2025-10-11 16:29:40

yes it seem it does:

method call time=1760199887.279435 sender=:1.245 -> destination=org.freedesktop.systemd1 serial=5 path=/org/freedesktop/systemd1; interface=org.freedesktop.systemd1.Manager; member=StartTransientUnit
   string "app-com.vivaldi.Vivaldi-78064.scope"
   string "replace"
   array [
      struct {
         string "PIDs"
         variant             array [
               uint32 78064
            ]
      }
   ]
   array [
   ]

Here is the entire log of vivaldi without fireajil: https://paste.ofcode.org/73q2sqCNviNjTLRaDYtraK

Last edited by Succulent of your garden (2025-10-11 16:33:06)

seth · 2025-10-11 22:02:45

As you can see, it shows up w/ a reasonable PID - the other one is likely context-relative to firejail and systemd cannot/will not replace PID 7
Is vivaldi from the repos or some appimage/snap/flatpak or are you explicitly trying to cscope it like in https://forum.vivaldi.net/topic/54898/l … -ram-usage ?

Succulent of your garden · 2025-10-12 11:29:02

seth wrote:

As you can see, it shows up w/ a reasonable PID - the other one is likely context-relative to firejail and systemd cannot/will not replace PID 7

Mmmhhh it does make sense. I made a pgrep firejail and pgrep vivaldi with vivaldi running in firejail mode. I saw in the terminal that in both pgrep-s the pid number is above 1 thousand. Pgrep firejail does have two PIDs and vivaldi have much more, like 8 or ten maybe. I'm going to run dbus-session again to check if the pid change to a lower one and track which process is, because with pgrep I can only see normal PID numbers and not very low like the 7 one.

seth wrote:

Is vivaldi from the repos or some appimage/snap/flatpak or are you explicitly trying to cscope it like in https://forum.vivaldi.net/topic/54898/l … -ram-usage ?

no to any of that. I''m running vivaldi-stable from the extra repo because Arch is great ^^ .

Succulent of your garden · 2025-10-12 14:35:18

So I search with dbus-monitor --session and it seems that always pick PID 7. I went to search what is PID 7 and it is kworker/R-slub_flushwq , which seems to be a kernel memory handler which is called slab.

Not sure if that's fine or not, I can see other vivaldi processes in user space with other PIDs, but it seems the master one is PID 7. Does that make sense to you while using fireajail ?

EDIT: There is a process called fireajil vivaldi --blabla flag ozone X11 that is in userspace i think, because it have a normal PID avobe the 1000 number, so maybe PID 7 is not the master one, but it is related to firejail vivaldi blabalbla

Last edited by Succulent of your garden (2025-10-12 14:38:45)

seth · 2025-10-12 15:17:45

It's reasonable for jailed processes to have their own PID count - the problem is the StartTransientUnit is effectively trying to escape that jail (by talking to the system bus) and rn I cannot tell why vivaldi/electron would do that, but it certainly does.
The error shows up in https://github.com/netblue30/firejail/issues/6857

Succulent of your garden · 2025-10-12 16:31:16

seth wrote:

the problem is the StartTransientUnit is effectively trying to escape that jail (by talking to the system bus)

But do you think that the StartTransientUnit is able to break the jail 100% ? I mean the current jailing is useless ? Because in some sense it's working by that thread in PID 7 in isolation, or that's what I'm guessing.

seth wrote:

The error shows up in https://github.com/netblue30/firejail/issues/6857

Mmmhhh it does but that error was far worse because that person wasn't able to get internet to the software. It seems that also firejail development is a little bit slow for the latest release. Do you think is better to post the issue in the github of firejail ?

Do you recommend other sandboxings ? I mean I only know that for LInux this is some kind of limited, I'm currently assuming that firejail is probably the best maintained, but I don't think that using docker or flatpak could be a thing. I mean it seems that vivaldi doesn't have any official docker image or flatpak packge, they only provide the package for different distros and snap support, which the last one is too bloated for me . But probably the god of destruction could know some random sandboxing or some black magic technique using cgroups in linux

Last edited by Succulent of your garden (2025-10-12 16:33:12)

xerxes_ · 2025-10-12 18:37:09

Start vivaldi from terminal with these options to see if there is any difference:

firejail --private vivaldi
firejail --private vivaldi --incognito
firejail --private --private-cache vivaldi
firejail --private --private-cache vivaldi --incognito
firejail --private --private-dev vivaldi
firejail --private --private-cache --private-dev vivaldi
firejail --private --private-cache --private-dev vivaldi --incognito

Succulent of your garden · 2025-10-27 13:13:20

Finally time to big brain more here! ^^ First thanks xerxes_ for you help. I tried that but sadly it doesn't help in anything, it does make the same behavior. The only added thing that I can say is that when you do one of the firejail --private things it does take the same amount of time than without it, but after making one if I run a vivaldi without the --private flag then it launches quickly, that's obviously because of ram access, the program had been inserted into ram and is ready for launching. Here are the logs of firejail --private *

Child process initialized in 205.74 ms
[14:14:1027/090034.944899:ERROR:components/search_engines/search_engines_managers_factory.cc:78] File can't be read: ~/.config/vivaldi/search_engines.json
[14:14:1027/090034.947976:ERROR:components/search_engines/search_engines_managers_factory.cc:78] File can't be read: ~/.config/vivaldi/search_engines_prompt.json
[14:14:1027/090035.257699:ERROR:chromium/dbus/object_proxy.cc:573] Failed to call method: org.freedesktop.systemd1.Manager.StartTransientUnit: object_path= /org/freedesktop/systemd1: org.freedesktop.DBus.Error.InvalidArgs: Process 14 is a kernel thread, refusing.
[14:14:1027/090035.267589:ERROR:chromium/dbus/object_proxy.cc:573] Failed to call method: org.freedesktop.DBus.Properties.GetAll: object_path= /org/freedesktop/UPower/devices/DisplayDevice: org.freedesktop.DBus.Error.ServiceUnknown: The name is not activatable
[14:14:1027/090035.273009:ERROR:chromium/dbus/object_proxy.cc:573] Failed to call method: org.freedesktop.DBus.Properties.Get: object_path= /org/freedesktop/portal/desktop: org.freedesktop.DBus.Error.InvalidArgs: No such interface “org.freedesktop.portal.FileChooser”
[14:41:1027/090037.711682:ERROR:chromium/google_apis/gcm/engine/registration_request.cc:291] Registration response error message: PHONE_REGISTRATION_ERROR
[14:41:1027/090037.722836:ERROR:chromium/google_apis/gcm/engine/registration_request.cc:291] Registration response error message: PHONE_REGISTRATION_ERROR
[14:41:1027/090037.728959:ERROR:chromium/google_apis/gcm/engine/registration_request.cc:291] Registration response error message: PHONE_REGISTRATION_ERROR
[14:41:1027/090037.795274:ERROR:chromium/google_apis/gcm/engine/mcs_client.cc:700]   Error code: 401  Error message: Authentication Failed: wrong_secret
[14:41:1027/090037.795286:ERROR:chromium/google_apis/gcm/engine/mcs_client.cc:702] Failed to log in to GCM, resetting connection.

Not sure if this could be made also by the gpu or amd driver to be honest. I notice that when I put the gpu with heavy load, this start to have issues with window switching or small delay rendering, mostly when I'm doing inference with LLMs and plus running also virtual machines without gpu passthrough. But when I'm doing normal activity the gpu seems fine. When I'm not doing LLM inference, I'm assuming that I'm not using ROCm, therefore without ROCM usage the gpu seems normal in any sense, so I believe that those bugs can came from ROCm usage and not by the amd driver itself, because in normal computer activity the gpu just works without any issues. Also it's a vivaldi + firejail usage, because without firejail vivalid just launch quickly, and other browsers + firejail works well and launch quick.

But I'm not sure how much could be a thing the amd driver, soon I'm going to switch to nvidia, probably copium but maybe the nvidia driver will not have this issue, also the first part of the log seems that is detecting my oldest nvidia gpu, not sure if that's creating the issue, I don't think so.

The last thing is the kernel, is LTS, but I also don't think that if I switch to latest release this could be solved.

what do you think about sending the journalctl -b logs ? I checked and it seems there could be some things on it to troubleshoot also, maybe there are linked with this.

Last edited by Succulent of your garden (2025-10-27 13:13:39)

seth · 2025-10-27 15:16:30

I thought we had figured that the failure to start the transient unit (inherited from chromium) is causing the slowdown?
https://bbs.archlinux.org/viewtopic.php … 4#p2267264

You could file an upstream bug (against firejail) - Idk how to offset the PID, but here's a completely fucked up approach
/usr/local/bin/vivaldi

#!/bin/bash
for ((i=0;i<1000;++i)); do
   /usr/bin/true
done
exec /usr/bin/vivaldi "$@"

Don't forget to "chmod +x /usr/local/bin/vivaldi" and then firejail that?
The true processes should™ ramp up the PID counter fast and hopefully make systemd happy?
It might however be necessary to leak the external PID into the jail

Succulent of your garden · 2025-10-29 11:18:24

seth wrote:

I thought we had figured that the failure to start the transient unit (inherited from chromium) is causing the slowdown?
https://bbs.archlinux.org/viewtopic.php … 4#p2267264

well yeah you are right, but I want to drop all other possible ways to fix this and reply to xerxes_ suggestion. It seem all failed :C

I wait a couple of days to reply this part coming part because I was not sure if this was joking or not LoL, I was too tired and also need to do other stuff.

seth's code wrote:

#!/bin/bash
for ((i=0;i<1000;++i)); do
/usr/bin/true
done
exec /usr/bin/vivaldi "$@"

You mean running that script with fireajil right ? Like firejail my.script.sh right ?

Why do you need the for loop also ? I'm curious

I could send an issue to firejail, but I think that probably someone over there had already know about the issue or this is happening to me because of my special stack of gpus, which is a nvidia + amd. I mean the firejail process first detects the nvidia card drive but then goes nope because it chooses the amd as the first one. Probably I'm just copium myself but i'll update dwm before and maybe at that time I'll replace the gpu with the nvidia and see what happens, because in that scenario I would just only have one driver for one gpu and the other one just for gpu passthrough, so host system would only have one gpu driver. Probably extreme copium but well I want to be sure that it's coming from firejail first instead of later being ohh duuuhh sorry guys it was my pc configuration.

I guess for now I could launch vivaldi without firejail with my dmenu for normal browser things, and use the firejail one when I believe I could need it

Last edited by Succulent of your garden (2025-10-29 11:19:41)

seth · 2025-10-29 15:25:48

You mean running that script with fireajil right ? Like firejail my.script.sh right ?

Yes.

Why do you need the for loop also ? I'm curious

The idea is to consume the lower PIDs inside the jailed context so systemd won't bitch around about PID 7 being a kernel thread (which it is, the PID is wrong in this context)
Idk whether that'll actually work, though.

I think that probably someone

"ass·u·me"

or this is happening to me because of my special stack of gpu

No.
vivaldi start the transient service (unconditionally) and systemd rejects that because of the "wrong" PID from the jailed context.

Succulent of your garden · 2025-10-29 19:46:54

seth wrote:

The idea is to consume the lower PIDs inside the jailed context so systemd won't bitch around about PID 7 being a kernel thread (which it is, the PID is wrong in this context)
Idk whether that'll actually work, though.

Thanks for the explanation and for the other ones also in your last post

I'm going to see if this change in the future, during the year I had this issue coming back and going, now it seems more persistent with more weeks. I'm going to wait a little bit because I'm with too much things to do to post a nice bug report in the firejail repo.

But sincerely many thanks for all your help in this post Seth ^^

Arch Linux

#26 2025-10-04 19:43:29

Re: Is vivaldi starting to start more slowly to anyone here ?

#27 2025-10-04 19:58:41

Re: Is vivaldi starting to start more slowly to anyone here ?

#28 2025-10-04 20:19:12

Re: Is vivaldi starting to start more slowly to anyone here ?

#29 2025-10-04 20:43:30

Re: Is vivaldi starting to start more slowly to anyone here ?

#30 2025-10-05 07:22:13

Re: Is vivaldi starting to start more slowly to anyone here ?

#31 2025-10-05 10:02:29

Re: Is vivaldi starting to start more slowly to anyone here ?

#32 2025-10-05 12:06:01

Re: Is vivaldi starting to start more slowly to anyone here ?

#33 2025-10-05 12:55:45

Re: Is vivaldi starting to start more slowly to anyone here ?

#34 2025-10-11 12:58:38

Re: Is vivaldi starting to start more slowly to anyone here ?

#35 2025-10-11 13:49:38

Re: Is vivaldi starting to start more slowly to anyone here ?

#36 2025-10-11 16:29:40

Re: Is vivaldi starting to start more slowly to anyone here ?

#37 2025-10-11 22:02:45

Re: Is vivaldi starting to start more slowly to anyone here ?

#38 2025-10-12 11:29:02

Re: Is vivaldi starting to start more slowly to anyone here ?

#39 2025-10-12 14:35:18

Re: Is vivaldi starting to start more slowly to anyone here ?

#40 2025-10-12 15:17:45

Re: Is vivaldi starting to start more slowly to anyone here ?

#41 2025-10-12 16:31:16

Re: Is vivaldi starting to start more slowly to anyone here ?

#42 2025-10-12 18:37:09

Re: Is vivaldi starting to start more slowly to anyone here ?

#43 2025-10-27 13:13:20

Re: Is vivaldi starting to start more slowly to anyone here ?

#44 2025-10-27 15:16:30

Re: Is vivaldi starting to start more slowly to anyone here ?

#45 2025-10-29 11:18:24

Re: Is vivaldi starting to start more slowly to anyone here ?

#46 2025-10-29 15:25:48

Re: Is vivaldi starting to start more slowly to anyone here ?

#47 2025-10-29 19:46:54

Re: Is vivaldi starting to start more slowly to anyone here ?

Board footer