Electron-updater: Appimage linux updater fails with ENOSYS: function not implemented

[JustTNE]

• Version: 4.1.2 (electron-updater)

• Target: Linux Appimage, Manjaro Linux

Electron updater errors out with the following logs:

Checking for update...
Found version 1.1.70727281 (url: sag-electron-1.1.70727281.AppImage)
Update available.
Downloading update from sag-electron-1.1.70727281.AppImage
updater cache dir: /home/elite/.cache/sag-electron-updater
Update has already been downloaded to /home/elite/.cache/sag-electron-updater/pending/sag-electron-1.1.70727281.AppImage).
Update downloaded; will install in 1 seconds
Auto install update on quit
Install: isSilent: true, isForceRunAfter: false
Error: Error: ENOSYS: function not implemented, unlink '/run/user/1000/appimagelauncherfs/0001.AppImage'
    at Object.unlinkSync (fs.js:1008:3)
    at AppImageUpdater.doInstall (/tmp/.mount_sag-elLEvSvQ/resources/app.asar/node_modules/electron-updater/out/AppImageUpdater.js:144:9)
    at AppImageUpdater.install (/tmp/.mount_sag-elLEvSvQ/resources/app.asar/node_modules/electron-updater/out/BaseUpdater.js:71:19)
    at /tmp/.mount_sag-elLEvSvQ/resources/app.asar/node_modules/electron-updater/out/BaseUpdater.js:104:12
    at App.<anonymous> (/tmp/.mount_sag-elLEvSvQ/resources/app.asar/node_modules/electron-updater/out/ElectronAppAdapter.js:60:48)
    at Object.onceWrapper (events.js:282:20)
    at App.emit (events.js:199:15)
    at App.<anonymous> (/tmp/.mount_sag-elLEvSvQ/resources/app.asar/main.js:41:42)
    at App.emit (events.js:199:15)

What's interesting to note here is that /run/user/1000/appimagelauncherfs/ contains copies of appimages that are currently running. The error log implies that process.env.APPIMAGE does not return the path where the file was started from (by the user). I suspect that this is an issue with AppImageLauncher, which is the default method of integrating and running appimages on a lot of systems. This could easily be solved if there was some way of knowing what directory the appimage was actually started from.

Package.json: https://gitlab.com/nullworks/accgen/accgen-electron-app/blob/CD/package.json
Node ver: v11.15.0
Npm ver: 6.10.0

[Ashesh3]

I'm having the same issue.

[dextronox]

Yep, same issue.

[AhMyth]

same here

[143mailliw]

Same issue on arch.

[JustTNE]

@develar Any chance we could get some input from you here? I'd be willing to contribute, but I have no clue how to get the actual appimage path as of right now.

[mcous]

I came up with a very dirty workaround that I'm not going to ship to my users because it feels way too brittle. I think until this is resolved I have to warn my users to not use AppImageLauncher

Anyway, when AppImageLauncher has launched an app, it sets the environment variable DESKTOPINTEGRATION to AppImageLauncher, so we can know if the AppImage was launched via AppImageLauncher.

Additionally, the environment variable ARGV0 seems to be set to the path to the source AppImage in ~/Applications. So, I've had a successful auto-update if I insert this piece of code before running electron-updater:

// HACK(mc, 2019-09-10): work around https://github.com/electron-userland/electron-builder/issues/4046
if (process.env.DESKTOPINTEGRATION === 'AppImageLauncher') {
  // remap temporary running AppImage to actual source
  // THIS IS PROBABLY SUPER BRITTLE AND MAKES ME WANT TO STOP USING APPIMAGE
  updater.logger.info('rewriting $APPIMAGE', {
    oldValue: process.env.APPIMAGE,
    newValue: process.env.ARGV0,
  })
  process.env.APPIMAGE = process.env.ARGV0
} else {
  updater.logger.info('Not running in AppImageLauncher')
}

I am categorically not going to ship this to users but your risk-tolerance may be different than mine

[JustTNE]

If ARGV0 is consistent, then this can easily be up-streamed into electron builder.

[ozooner]

@mcous - Thanks for posting the workaround. I guess the long-term solution is probably to start using the AppImageUpdate utility instead to provide updates to end users. I am not happy about it either as we have (had) a perfectly working system...

I don't think that the ARGV0 is as brittle solution as you think. I would probably only do the swap right before installing the update. Looking through the code, it seems to be used by the AppImageLauncher quite explicitly as well, so I think it's here to stay.

Looking for argv[0] I came across a function that checks the file for updates. So one midway approach could also be to ditch the electron-updater and simply download the file to the AppImage's location and have the AppImageLauncher to take care of detecting the change and re-launching the app.

There's also the option of asking users to uninstall appimagelauncher ;)

[ozooner]

Okay, so for my use-case it's important that the update process is autonomous. By default the update process would create a new file in the Applications directory and execute it. This would prompt the user for 'integrate' or 'run once' dialog. I am not using version in the file name, so that electron-updater would overwrite the file so that the prompt wouldn't pop up. This works, however the appimagelauncher will still run the old version (from a cache somewhere), though the file itself has updated. I even went so far to manually replace the .AppImage with a different file in the Applications folder, and renamed the new AppImage exactly the same as previously 'integrated' one. It still runs the old version...

[stale]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[mcous]

I believe this issue is still relevant. AppImageLauncher is recommended by electron-builder for desktop integration, but electron-updater does not work with AppImageLauncher installed AppImages

[ghost]

I had this issue on Arch for almost half a year, it was never fixed, I did a new clean Arch reinstall and only that fixed it.

[TheAssassin]

Indeed this is more of an issue with Electron's updater than AppImageLauncher, this problem has been fixed in AppImageUpdate itself IIRC. Basically, the issue disappears if you don't use AppImageLauncher.

Right now there's nothing we can do in AppImageLauncher to help fix this issue, Electron's updater needs to implement a tiny workaround. @develar I'd like to help get this fixed, please feel free to ping me.

[Finn0811]

I have the same issue now. Looking forward for a fix.

[quanglam2807]

@mcous @ozooner Thank you very much for helping! So in conclusion, is the workaround by @mcous production-ready?

[dsafreno]

I'm running into the same issue, also from a user on Manjaro Linux. FWIW.

[mcous]

@quanglam2807 my company does not use that workaround in production, so I cannot vouch for it. We currently tell our users that they should not use AppImageLauncher

[quanglam2807]

@quanglam2807 my company does not use that workaround in production, so I cannot vouch for it. We currently tell our users that they should not use AppImageLauncher

Thank you for the clarification! I couldn’t wait for your answer so I decided to use it anyway in production. But luckily, I haven’t heard any complains.

[ozooner]

I could not get this workaround to work properly, it could be because I had an additional requirement that the updated AppImage should have the same filename as before. What happened in that case was that the file was overwritten with a new file, however when launched, it still launched the old version of the app from some AppImage cache/storage.

After spending half a day on the issue I also gave up and concluded this is not something we can work around from inside our app (or the solution would be too hacky). We detect the AppImageLauncher and advise our users to uninstall it if they want automatic updates to work properly.

if(process.env.DESKTOPINTEGRATION === 'AppImageLauncher'){...}

For users that did not uninstall AppImageLauncher we simply don't install updates to keep their current version running without the errors.

[TheAssassin]

It's sad to see zero reaction from the electron builder team. I'm not a fan reading when people (have to?) recommend users to uninstall AppImageLauncher entirely for some auto-update (which I'm not a fan of) or general updates to work as intended. If there were a workaround I could implement, that'd be no problem, but it's really not that hard to fix the problem in the Electron updater itself.

The AppImage type 3 currently discussed here fixes the need for AppImageLauncher to ship with a custom FUSE filesystem which could cause trouble. binfmt_misc is to blame here, too.

@ozooner @mcous please recommend your users AppImageLauncher Lite instead of uninstalling AppImageLauncher entirely. The Lite version is not affected by this bug. And it provides at least some better desktop integration.

[JustTNE]

@TheAssassin would you recommend users (of electron-builder) to set X-AppImage-Integrate=false in the .desktop file for now? I've been forced to do that for one of my other apps (not electron) because my self updating appimage is not working well with appimagelauncher.

[TheAssassin]

No, that would not solve the issue at all. Neither does uninstalling, it's basically just a baaaad hack.

[stale]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[quanglam2807]

Not stale, bot.

[abdurrahmanyildirim]

Any update?

[abdurrahmanyildirim]

this solution #4046 (comment) works for me but you should include it inside of update-downloaded event otherwise users cant see update progress. If you dont use it in update-download event, it works so fast or doesnt work well

autoUpdater.on('update-downloaded', () => {
   if(process.env.DESKTOPINTEGRATION === 'AppImageLauncher') {
     process.env.APPIMAGE = process.env.ARGV0;
   }
})

[TheAssassin]

Should be resolved once the upcoming release of AppImageLauncher has been published. It replaces the FUSE filesystem with a (hopefully) more robust solution. See TheAssassin/AppImageLauncher#361 for more information. No need for additional workarounds.

Looking for testers of the new method! Please report feedback in TheAssassin/AppImageLauncher#361.

Edit: tried two AppImages (one of them is Jitsi Meet), the update worked as intended. Still not a fan of the custom method (would prefer an integration with AppImageUpdate), but it works now.

[adam-lynch]

The AppImageLauncher fix was released. I tried it and it worked fine for me. This could be closed?

[ozooner]

@adam-lynch do you know which version contains the fix?

[adam-lynch]

@ozooner 2.2.0, see TheAssassin/AppImageLauncher#361

[stale]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[PaluMacil]

This was still happening with uninstall and reinstall for me for the last 15 months till today. Finally today I noticed that the latest/edge channel that I was on hasn't been updated since the problem started. latest/stable has the actual latest version. I uninstalled and then switched channels and reinstalled. I guess next time there is an update I'll know if this is still broken or if it can update now. If you're reading this, make sure you switch to latest/stable since if you were on edge to try to get the fix faster, you were stuck on an old version.

[PaluMacil]

hm, maybe I am remembering how this bug worked wrong... it looks like I'm using snap now, not appimage, and this bug was for app image. I must have switched in my attempt to get it working and long forgot. Regardless, you do need the latest/stable channel for snap or you'll be stuck on the broken version.