Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

AppImage built with webkit2gtk dependencies cannot start on non-Ubuntu distributions

See original GitHub issue

The issue is described in eneshecan/whatsapp-for-linux#160. Here is just the error:

<13>Jan 21 23:42:13 whatsapp-for-linux[7682]: ** (whatsapp-for-linux:7676): ERROR **: 23:42:13.184: Unable to spawn a new child process: Failed to execute child process “/usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/WebKitNetworkProcess” (No such file or directory)

This is a fix for the issue in another framework that supports building AppImage binaries: tauri-apps/tauri#2940


Issue Analytics

  • State:open
  • Created 2 years ago
  • Reactions:1
  • Comments:5 (4 by maintainers)

github_iconTop GitHub Comments

AlexTMjugadorcommented, Dec 20, 2022

@andrewda I’m glad my writeup was helpful!

I’m curious how you tested this with appimage-builder. Could you share your process or patch? I’d love to try something similar on my end and play around with getting something to work.

Sure! I just used an after_bundle script, inspired by Tauri’s scripts.

AlexTMjugadorcommented, Nov 17, 2022

I’m developing an application that depends on WebKitGTK and I’ve stumbled upon this issue. Setting path mappings does like this in the recipe file does not work:

      - /usr/lib/x86_64-linux-gnu/webkit2gtk-4.0:$APPDIR/usr/lib/x86_64-linux-gnu/webkit2gtk-4.0

After reading the AppRun and WebKitGTK source code, in addition to testing on my Linux box by breaking WebKitGTK on purpose by running sudo mv /usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/WebKitWebProcess /usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/.WebKitWebProcess (this is a terrible thing to do, please don’t copy and paste this command), I’ve arrived at the following conclusions:

  • Path mappings do not work because the WebKitGTK spawns those processes using posix_spawn, fork or exec, and as far as I can tell the AppRun hooks do not touch all of these functions.
    // Warning: we want GIO to be able to spawn with posix_spawn() rather than fork()/exec(), in
    // order to better accommodate applications that use a huge amount of memory or address space
    // in the UI process, like Eclipse. This means we must use GSubprocess in a manner that follows
    // the rules documented in g_spawn_async_with_pipes_and_fds() for choosing between posix_spawn()
    // (optimized/ideal codepath) vs. fork()/exec() (fallback codepath). As of GLib 2.74, the rules
    // relevant to GSubprocess are (a) must inherit fds, (b) must not search path from envp, and (c)
    // must not use a child setup fuction.
    // Please keep this comment in sync with the duplicate comment in XDGDBusProxy::launch.
    GRefPtr<GSubprocessLauncher> launcher = adoptGRef(g_subprocess_launcher_new(G_SUBPROCESS_FLAGS_INHERIT_FDS));
    g_subprocess_launcher_take_fd(launcher.get(), socketPair.client, socketPair.client);

(From the webkitgtk-2.38.2 release, file WebKit/UIProcess/Launcher/glib/ProcessLauncherGLib.cpp)

  • WebKitGTK supports setting the WEBKIT_EXEC_PATH environment variable to change the path where binaries are expected to be at runtime, but it only does so if the developer mode flag is enabled when building WebKitGTK. This is not the case for Debian Bullseye packages, for example, so it can’t be relied upon. (Source: the findWebKitProcess function at WebKit/Shared/glib/ProcessExecutablePathGLib.cpp)

I don’t know what the rationale of the WebKitGTK team was to lock down the WEBKIT_EXEC_PATH environment variable behind a developer mode flag (if an attacker can set arbitrary environment variables, can’t it already change the behavior of the dynamic linker and/or the WebKit binary itself to run malicious code?), but the only feasible way I can see to deal with this is to do what Tauri did in the linked issue and binary-patch the strings embedded in the libraries. Or patch AppRun to hook the process spawning calls, but I’m not sure how feasible is that to do.

The main problem with Tauri’s approach is that I’ve tested it, and it doesn’t work for appimage-builder as-is. Tauri’s solution replaces the offending /usr path prefix by ././, so it probably relies on the working directory being set to some value that differs in appimage-builder:

$ LC_ALL=C ../../target/appimage/PackSquash\ \(GUI\)-v0.3.1-333-g86df839-custom-x86_64.AppImage
Gtk-Message: 20:36:37.367: Failed to load module "colorreload-gtk-module"
Gtk-Message: 20:36:37.373: Failed to load module "window-decorations-gtk-module"

** (packsquash-gui:28576): ERROR **: 20:36:37.826: Unable to spawn a new child process: Failed to spawn child process ?././/lib/x86_64-linux-gnu/webkit2gtk-4.0/WebKitNetworkProcess? (No such file or directory)
[1]    28576 trace trap  LC_ALL=C

For completeness and reference purposes, this is the relevant script that Tauri uses to generate the AppDir and patch the WebKitGTK binaries.

Edit: I found out the rationale for WEBKIT_EXEC_PATH being only honored on development builds. Some WebKit developer thought on 2014 that environment variable was only useful for “internal tools and tests”, and decided to gate it behind that flag, with the approval of another developer. Clearly they didn’t have AppImages in mind 😅

Edit 2: oddly enough, when mounting the AppImage with --appimage-mount and trying to run the offending WebKit processes from a terminal, I’m also greeted with a “No such file or directory” error, despite the file being there and having execute permission. Perhaps it’s necessary to tweak some ELF loader bits too?

Edit 3: the error I mentioned on “Edit 2” was caused due to appimage-builder relativizing the path to the dynamic link interpreter to lib64/ Switching the working directory to the runtime directory within the AppImage filesystem worked. This suggests that maybe Tauri’s workaround is okay, but the missing piece is getting the spawned process to use the dynamic linker embedded in the AppImage.

Sadly, all of this means that AppImages containing applications that depend on WebKitGTK don’t work properly, relying on WebKitGTK binaries to be present in the target system. I hope that my thorough description at least is useful to give more insight on what’s going on and possible ways to tackle it.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Bottles AppImage · Issue #1272 · bottlesdevs/Bottles - GitHub
Bottles need 1.6 but Ubuntu 21.10 is stuck with 1.2. I think the Appimage can be built using any distro, right?
Read more >
[SOLVED] Debug Appimage? -
This Appimage works in some system or it would hardly be released, but fails in Slackware giving this output in an xterm Code:...
Read more >
Can't run AppImage on desktop by doubleclicking or clicking ...
Solution 1 : Right Click On The Appimage File And Go In Properties. enter image description here. Then Go In Permissions.
Read more >
Blank lines of SVG 1.2 text aren't rendered anymore - GitLab
Right now, the latest APPImage of Inkscape its working as expected (V1.0.1). Can create text with spaces between lines. no issues.
Read more >
How to Build a Cross-Platform Application with Next.js and Tauri
Canonical provides all Linux application distributions and does not work for macOS and Windows. Before building a snap, first you need to ...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found