mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #4173] gnome-calculator hangs with 100% CPU #2563
Labels
No labels
LTS merge
LTS merge
bug
bug
converted-to-discussion
doc-todo
documentation
duplicate
enhancement
file-transfer
firecfg
firejail-in-firejail
firetools
graphics
help wanted
information_old
installation
invalid
modif
moved
needinfo
networking
notabug
notourbug
old-version
overlayfs
packaging
profile-request
pull-request
question
question_old
removal
runtime-permissions
sandbox-ipc
security
stale
wiki
wiki
wontfix
wordpress
workaround
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/firejail#2563
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @dsprenkels on GitHub (Apr 8, 2021).
Original GitHub issue: https://github.com/netblue30/firejail/issues/4173
Write clear, concise and in textual form.
Bug and expected behavior
On my computer starting
gnome-calculatorwith firejail on (i.e.,firejail --profile=/etc/firejail/gnome-calculator.profile /usr/bin/gnome-calculator) results in no window appearing andgnome-calculatorrunning in the background with 100% CPU, until terminated manually.No profile and disabling firejail
Running
firejail --noprofile /usr/bin/gnome-calculatorresults in the program working correctly.Reproduce
Steps to reproduce the behavior:
Environment
Additional context
I started commenting out lines from the profile, and seeing if I could get it to work. The bug was fixed when commenting
include disable-shell.incandprivate-bin gnome-calculator.The resulting (fixed) profile:
gnome-calculator.profile.txt
I do not know why
gnome-calculatorseems to need a shell in my environment, and what is different in my setup that this bug is being triggered. Though I'm happy to provide extra information.Checklist
https://github.com/netblue30/firejail/issues/1139)--profile=PROFILENAMEis used to set the right profile. (n/a)LC_ALL=en_US.UTF-8 LANG=en_US.UTF-8 PROGRAMto get english error-messages.browser-allow-drm yes/browser-disable-u2f noinfirejail.configto allow DRM/U2F in browsers.debug output
@rusty-snake commented on GitHub (Apr 8, 2021):
Is
/usr/bin/gnome-calculatora shell script in Arch?Does it work with
BTW: I read your title as "gnome-calculator does not (start with 100% CPU)" instead of "gnome-calculator does (not start) with 100% CPU". Maybe "gnome-calculator does not start, consuming 100% CPU" would be more clear.
@ghost commented on GitHub (Apr 8, 2021):
I've reinstalled gnome-calculator on my Arch Linux box to test this. For now I cannot reproduce.
These warnings stem from gnome-calculator's 'Financial Mode', relying on currency exchange rates. As those rates fluctuate GC tries to cache them. It's not uncommon to see these warnings. They usually go away when caching succeeded until they are refreshed (controlled by a pref that comes with 'never', 'daily' or 'weekly'). This functionality is working fine for me with the current gnome-calculator.profile.
In your gnome-calculator.profile.txt I see
#caps.drop alltoo. Is this a leftover from your attempt to fix whatever is happening to GC? Or do you actually need to have that commented too for the app to work?A proper debug log might be helpful in this context. Run
firejail --debug /usr/bin/gnome-calculator | tee ${HOME}/Downloads/gnome-calculator.debug.log, use the app and attach the log file here please.@jose1711 commented on GitHub (Apr 10, 2021):
Arch Linux x86_64 here too + cannot reproduce the issue
@dsprenkels commented on GitHub (Apr 13, 2021):
Somehow this comment did not get posted last time, and I did not notice, so let's try again:
Nope. It's an ELF binary:
Nope. However, commenting out the
private-bindirective again does fix it.So presumably there is some binary that wants to be accessed. However, I cannot seem to find it:
strace -ff -e trace=process /usr/bin/gnome-calculator
Also stracing file operations and grepping on
bingives no results:strace -ff -e trace=file /usr/bin/gnome-calculator
Yes, this was leftover from my debugging efforts. Changing this line has no impact on whether it works or not.
Sure thing:
@ghost commented on GitHub (Apr 13, 2021):
Thanks for clearing things up and providing the logs. I can't immediately spot anything fishy in those. Do you have anything in your globals.local that might interfere? Also, the gnome-calculator package on Arch Linux contains two executables in /usr/bin:
gnome-calculatorandgcalccmd.The latter has its own separate firejail profile BTW. And then there'sgnome-calculator-search-providerin /usr/lib. So here's another 'wild' guess to try:EDIT: that doesn't make any sense and I would be surprised if it fixed your issue. Still can't explain why I cannot reproduce. Could be a tough nut to crack...
@rusty-snake commented on GitHub (Apr 14, 2021):
Does
firejail --build gnome-calculatorshow anything interesting in the generatedprivate-binline?@dsprenkels commented on GitHub (Apr 16, 2021):
Ok. After adding this line:
it worked. But when I started removing gcalccmd and other parts it kept working, until I had:
When I looked at the line that I used previously:
private-bin gnome-calculator, sh, bash.I was unaware that the extra spaces after the commas would break this line.
Removing that single space before
shfixed the issue. Though I still do not know why on my setupgnome-calculatorneeds a shell.@ghost commented on GitHub (Apr 16, 2021):
Extra spaces indeed break several of firejail's options. Too bad you had to discover this the hard way. I for one also missed it in trying to figure out what was happening on your system. Lesson learned all round I guess.
Can't explain that either. Looking at your posted gnome-calculator.debug-with-profile.log once more, the only override we haven't looked at yet is
globals.local.Anything in there that might be related?@dsprenkels commented on GitHub (Apr 16, 2021):
My
globals.local's content is only:I don't think that should matter.
EDIT: Just to be sure, I double-checked this. As expected, it does not fix the problem.
@dsprenkels commented on GitHub (Apr 16, 2021):
Would it maybe be an idea to add a warning when this occurs?
@ghost commented on GitHub (Apr 16, 2021):
That one line globals.local is indeed irrelevant in this context, what keeps the hunt ongoing for why you need sh in the first place.
That sure is a sound idea. I'll add the
enhancementtag to this to attract more attention to such a feature. Fingers crossed and if you ever find out why your gnome-calculator needs sh, please add that here.EDIT: perhaps you can add something like "private-bin containing spaces break without error" to the issue title to better reflect this
@rusty-snake commented on GitHub (Apr 16, 2021):
FTR: Spaces in files/paths in firejail profiles need no escape because they are treated as any other char. Therefore
private-bin gnome-calculator, shtells firejail to create a private-bin withgnome-calculatorandsh(leading space). That's the expected and wanted behaviour (ATM). However files starting/ending with a space is very uncommon because you can see it depending on the display context. Showing an error for these case should not break any real existing case.@dsprenkels commented on GitHub (Apr 16, 2021):
Ok. I narrowed down the bug to
cd619d3e9d/libproxy/modules/config_gnome3.cpp (L128-L161), in particular this loop:cd619d3e9d/libproxy/modules/config_gnome3.cpp (L158-L160)I may look into the cause of the bug a bit more; or just open an issue in the libproxy repo. In any case, feel free to close this issue.
@rusty-snake commented on GitHub (Apr 16, 2021):
Call to
popen2:cd619d3e9d/libproxy/modules/config_gnome3.cpp (L147)execl/bin/sh:cd619d3e9d/libproxy/modules/config_gnome3.cpp (L101)EDIT: used to start
/usr/libexec/pxgsettingsEDIT2: Any non-default in
gsettings list-recursively org.gnome.system.proxy?@dsprenkels commented on GitHub (Apr 16, 2021):
My
gsettings list-recursively org.gnome.system.proxycontents:It doesn't look like there is anything weird in there.
I patched libproxy to provide me with some output to actually test that it is actually that specific while loop that is breaking. It is.
However, when I run
gnome-calculatoroutside of firejail, it looks like that function never gets called.I am currently starting
gnome-calculatorand then attaching to it with gdb from a different shell using root permissions. However, I am too late to debug the beginning of the program this way. Do some of you have any advice on how to run gdb directly inside firejail (or start the program without actually running it)?@dsprenkels commented on GitHub (Apr 16, 2021):
Additionally: I checked that the call to
execlactually fails (it does). So I guess adding a check in that file to see ifshexists, before executing it, should probably fix the 100% CPU error. Though it would still be unclear why (in my obscure case)gnome-calculatoractually needs to start/usr/libexec/pxgsettings, while in other setups it doesn't.@rusty-snake commented on GitHub (Apr 16, 2021):
I did not even have this file / libproxy insallted. @glitsj16 you?
@ghost commented on GitHub (Apr 16, 2021):
No trace of /usr/libexec/pxgsettings on my Arch. I do have libproxy installed as a dependency for qt5-base, but my libproxy package contains /usr/lib/pxgsettings, not that libexec path
@dsprenkels Are you sure you are running a fully updated Arch Linux?
FTR, I have the same gsettings. I run firejail with
network noandrestricted-network yesBTW, no clue if that would make this kind of difference.@dsprenkels commented on GitHub (May 4, 2021):
I am sure I tested this using an updated Arch installation. It's weird.
Ok, this is probably problem. Let me investigate this further.No the file does not exist. This is expected.
@dsprenkels commented on GitHub (May 4, 2021):
I will close this issue for now. I feel bad exhausting your time tracking down such an obscure bug.
I will try investigating further myself, and report back if I find a cause or fix.
@jserafim commented on GitHub (Aug 30, 2022):
I'm having this exact issue, except that my environment is a bit different:
The quick workaround I'm using to avoid this:
Edit:
As suggested by @rusty-snake , if I understood correctly:
@rusty-snake commented on GitHub (Aug 30, 2022):
OT: Use locals