| Summary: | Attempting to run an AppImage that needs a --no-sandbox from UI just exits without helpful message | ||
|---|---|---|---|
| Product: | [I don't know] kde | Reporter: | Reuben <kde> |
| Component: | general | Assignee: | Unassigned bugs <unassigned-bugs-null> |
| Status: | CLOSED DOWNSTREAM | ||
| Severity: | normal | CC: | josh, kde, kdedev, nate |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Reuben
2025-02-06 11:38:06 UTC
How should we detect that certain executable needs a random (from the system pov) flag set? The appimage author should make sure that their appimage can run correctly or the appimage itself With respect, I don't think this addresses the issue. The issue is: running an AppImage can fail silently. That's unquivocally a bug. With regard to the flag being "random" - not sure I agree either, though this is more a question of how comprehensively KDE wants to support AppImages. a) AppImages can run in a sandbox or without a sandbox - that's a fundamental architecture - not a random flag. b) Electron is not exactly uncommon. And AppImages that were written in Electron all have this issue. It's detectable by KDE simply by looking at the stdout when you attempt to run it after the user clicks "Execute". It would be feasible for KDE to (as I suggested) pop up a second prompt explaining what happened to the user and offering one of two options. If it's not a goal for KDE to be able to run AppImages, then I'd suggest removing the current dialog, since it's half assed. Minimal fix here would be to at least show the output when it fails to run. I think a better fix is as I described. (In reply to Reuben from comment #2) > With regard to the flag being "random" - not sure I agree either, though > this is more a question of how comprehensively KDE wants to support > AppImages. > > a) AppImages can run in a sandbox or without a sandbox - that's a > fundamental architecture - not a random flag. Just a correction but your LLM is wrong, --no-sandbox is from the application - AppImages do not have anything to do with that. Oh. My bad! It appears to be an electron thing rather than AppImage thing then. https://www.reddit.com/r/debian/comments/hkyeft/unable_to_run_appimage_applications_without/ etc Indeed. Which means the app itself is either mis-written or mis-packaged. If it needs that flag to run successfully, it's the app's responsibility to do so. Really this is no different from any other misbehaving app. If an app successfully launches but then doesn't show a window or quits immediately, it's the app's fault, and there isn't really anything we can do about it. Showing STDOUT or STDERR won't work because 1) there's no guarantee anything will be printed there and 2) there's no guarantee anything printed there would be related to the issue. Lots of app (including many of our own, unfortunately) print a lot of junk there that doesn't actually indicate a problem. So please report this to the app's developer or AppImage packager. Thanks! > If it needs that flag to run successfully, it's the app's responsibility to do so.
Again, it's every electron AppImage. Not just this single one. This is not a random or niche thing.
They even exit with a specific non zero error code.
But yet another half finished KDE thing I guess. Fine.
Then it's every Electron app's responsibility, or Electron's responsibility. Basically, if the app is written or packaged so badly that it quits immediately after launching, that's the thing that needs to be fixed. Anything we could do on our side would be an unreliable and potentially misleading band-aid. So whoever is packaging these electron apps using AppImage needs to do some basic testing to make sure the app at least runs when launched using the GUI. That's literally the bare minimum. |