From d2e31148a0ae6635e854d829554d080275ce284b Mon Sep 17 00:00:00 2001 From: Wez Furlong Date: Sat, 9 Jan 2021 08:20:12 -0800 Subject: [PATCH] wezterm: workaround appimage startup issue AppImage passes fd 1023 opened on the mount point directory. If we close this prior to exec, some magic in appimage decides to unmount the fuse mount right before we're about to exec the wezterm-gui binary from the appimage. So, don't close stray fds when the cli spawns the gui when we're an appimage. See also: e831032c725ce2d4bc63f0bf1ecf33364cf72dac closes: #419 --- wezterm/src/main.rs | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/wezterm/src/main.rs b/wezterm/src/main.rs index f3412678d..ba0fa1da4 100644 --- a/wezterm/src/main.rs +++ b/wezterm/src/main.rs @@ -271,7 +271,13 @@ fn delegate_to_gui(saver: UmaskSaver) -> anyhow::Result<()> { #[cfg(unix)] { use std::os::unix::process::CommandExt; - portable_pty::unix::close_random_fds(); + // Clean up random fds, except when we're running in an AppImage. + // AppImage relies on child processes keeping alive an fd that + // references the mount point and if we close it as part of execing + // the gui binary, the appimage gets unmounted before we can exec. + if std::env::var_os("APPIMAGE").is_none() { + portable_pty::unix::close_random_fds(); + } return Err(anyhow::anyhow!("failed to exec: {:?}", cmd.exec())); }